🚀 New & Improved Data Mapper UX in Azure Logic Apps – Now in Public Preview!
We’re excited to announce that a UX update for Data Mapper in Azure Logic Apps is now in Public Preview! We have continuously improved Data Mapper, which is already generally available (GA), based on customer feedback. Last year, we conducted a private preview to assess the improvements in the new user experience and confirm that we are on the right track in simplifying complex data transformations, including EDI schemas. With the insights gained, we made significant UI enhancements and added features to streamline the mapping process. Feedback We value your feedback to make the Data Mapper even better. Please share your thoughts, suggestions, and overall experience with us through our feedback form. How feedback shaped the Public Preview Throughout the evolution of Data Mapper, we gathered valuable feedback from customers and partners. Key themes that emerged include: Reliability: Ensuring the Data Mapper can handle large schemas and complex transformation logic, including functions. Error handling: Providing real-time validation by allowing users to test payloads and catch errors while authoring maps. Looping: Clearly indicating when repeating nodes are mapped and ensuring complex objects are properly represented Drag & drop enhancements: Improving how connections between nodes are created for better usability. Deserialization & namespace honoring: Ensuring XML deserialization correctly loads mappings without data loss, preserving namespace integrity for seamless schema validation. We’ve incorporated these suggestions into the public preview, ensuring a more refined and user-friendly experience. What’s new in the Data Mapper UX? 1. Easier navigation Docked schema panels keep you oriented within the data map. Easily search for specific nodes to streamline mapping. 2. Side-by-side function panel Search and use 100+ built-in functions, including mainly: Collection functions (for repeating elements) String manipulations Mathematical operations Conditional logic 3. Automatic looping for repeating nodes When mapping repeating nodes, a new loop connection is automatically added on the immediate parent nodes at source and destination. Repeating parent nodes are denoted by "A1, A2" notation on hover. Note: If the child node in the source has a deeper nesting level than in the destination, you must manually map the connection from the repeating source node to the destination to ensure proper data transformation. 4. Real-time error detection On saving the map, instantly view warnings and errors for missing mappings or incorrect configurations 5. Test Your Map Instantly Preview the output before running your workflow. How to set up and test out the new Data Mapper experience Enable the Preview: Go to your Azure Logic App (Standard) extension -> Settings -> Data Mapper. Select “Version ~2” to try out the new user experience. Light theme: Enable "Light Theme" in VS Code before creating a new data map. Dark Theme is not supported, but is on the roadmap and will be prioritized soon. Create a New Data Map: Navigate to the Azure tab on the left-hand panel of your VS Code. Select “Create New Data Map” and name it. Once loaded, select the schemas for source and destination. Upload schemas: Upload your source and destination schemas before creating the map (eg .xsd or .json files). Limitations While the new Data Mapper UX brings significant improvements, a few limitations remain: Filter function: The filter function correctly processes numeric conditions when enclosed in quotes (e.g., ">= 10"), but does not behave consistently for string comparisons (e.g., checking if item name = "Pen"). We are actively working on refining this behavior. Custom Functions: Support for custom functions is coming in the next refresh to enhance flexibility in data mapping. Usability enhancements: Improved tooltips, function labels, error messages and other UX refinements are on the way to provide clearer guidance and a smoother mapping experience, especially for complex transformations. Future investments The product is going to continue getting better and we should be adding more features very soon! Some immediate investments include: Enhanced test map experience: Making it easier to validate mappings during development. Panel resizing: Allowing users to have flexibility in viewing larger schemas and functions when multiple panels are expanded.Azure API Management Your Auth Gateway For MCP Servers
The Model Context Protocol (MCP) is quickly becoming the standard for integrating Tools 🛠️ with Agents 🤖 and Azure API Management is at the fore-front, ready to support this open-source protocol 🚀. You may have already encountered discussions about MCP, so let's clarify some key concepts: Model Context Protocol (MCP) is a standardized way, (a protocol), for AI models to interact with external tools, (and either read data or perform actions) and to enrich context for ANY language models. AI Agents/Assistants are autonomous LLM-powered applications with the ability to use tools to connect to external services required to accomplish tasks on behalf of users. Tools are components made available to Agents allowing them to interact with external systems, perform computation, and take actions to achieve specific goals. Azure API Management: As a platform-as-a-service, API Management supports the complete API lifecycle, enabling organizations to create, publish, secure, and analyze APIs with built-in governance, security, analytics, and scalability. New Cool Kid in Town - MCP AI Agents are becoming widely adopted due to enhanced Large Language Model (LLM) capabilities. However, even the most advanced models face limitations due to their isolation from external data. Each new data source requires custom implementations to extract, prepare, and make data accessible for any model(s). - A lot of heavy lifting. Anthropic developed an open-source standard - the Model Context Protocol (MCP), to connect your agents to external data sources such as local data sources (databases or computer files) or remote services (systems available over the internet through e.g. APIs). MCP Hosts: LLM applications such as chat apps or AI assistant in your IDEs (like GitHub Copilot in VS Code) that need to access external capabilities MCP Clients: Protocol clients that maintain 1:1 connections with servers, inside the host application MCP Servers: Lightweight programs that each expose specific capabilities and provide context, tools, and prompts to clients MCP Protocol: Transport layer in the middle At its core, MCP follows a client-server architecture where a host application can connect to multiple servers. Whenever your MCP host or client needs a tool, it is going to connect to the MCP server. The MCP server will then connect to for example a database or an API. MCP hosts and servers will connect with each other through the MCP protocol. You can create your own custom MCP Servers that connect to your or organizational data sources. For a quick start, please visit our GitHub repository to learn how to build a remote MCP server using Azure Functions without authentication: https://aka.ms/mcp-remote Remote vs. Local MCP Servers The MCP standard supports two modes of operation: Remote MCP servers: MCP clients connect to MCP servers over the Internet, establishing a connection using HTTP and Server-Sent Events (SSE), and authorizing the MCP client access to resources on the user's account using OAuth. Local MCP servers: MCP clients connect to MCP servers on the same machine, using stdio as a local transport method. Azure API Management as the AI Auth Gateway Now that we have learned that MCP servers can connect to remote services through an API. The question now rises, how can we expose our remote MCP servers in a secure and scalable way? This is where Azure API Management comes in. A way that we can securely and safely expose tools as MCP servers. Azure API Management provides: Security: AI agents often need to access sensitive data. API Management as a remote MCP proxy safeguards organizational data through authentication and authorization. Scalability: As the number of LLM interactions and external tool integrations grows, API Management ensures the system can handle the load. Security remains to be a critical piece of building MCP servers, as agents will need to securely connect to protected endpoints (tools) to perform certain actions or read protected data. When building remote MCP servers, you need a way to allow users to login (Authenticate) and allow them to grant the MCP client access to resources on their account (Authorization). MCP - Current Authorization Challenges State: 4/10/2025 Recent changes in MCP authorization have sparked significant debate within the community. 🔍 𝗞𝗲𝘆 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀 with the Authorization Changes: The MCP server is now treated as both a resource server AND an authorization server. This dual role has fundamental implications for MCP server developers and runtime operations. 💡 𝗢𝘂𝗿 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻: To address these challenges, we recommend using 𝗔𝘇𝘂𝗿𝗲 𝗔𝗣𝗜 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 as your authorization gateway for remote MCP servers. 🔗For an enterprise-ready solution, please check out our azd up sample repo to learn how to build a remote MCP server using Azure API Management as your authentication gateway: https://aka.ms/mcp-remote-apim-auth The Authorization Flow The workflow involves three core components: the MCP client, the APIM Gateway, and the MCP server, with Microsoft Entra managing authentication (AuthN) and authorization (AuthZ). Using the OAuth protocol, the client starts by calling the APIM Gateway, which redirects the user to Entra for login and consent. Once authenticated, Entra provides an access token to the Gateway, which then exchanges a code with the client to generate an MCP server token. This token allows the client to communicate securely with the server via the Gateway, ensuring user validation and scope verification. Finally, the MCP server establishes a session key for ongoing communication through a dedicated message endpoint. Diagram source: https://aka.ms/mcp-remote-apim-auth-diagram Conclusion Azure API Management (APIM) is an essential tool for enterprise customers looking to integrate AI models with external tools using the Model Context Protocol (MCP). In this blog, we've emphasized the simplicity of connecting AI agents to various data sources through MCP, streamlining previously complex implementations. Given the critical role of secure access to platforms and services for AI agents, APIM offers robust solutions for managing OAuth tokens and ensuring secure access to protected endpoints, making it an invaluable asset for enterprises, despite the challenges of authentication. API Management: An Enterprise Solution for Securing MCP Servers Azure API Management is an essential tool for enterprise customers looking to integrate AI models with external tools using the Model Context Protocol (MCP). It is designed to help you to securely expose your remote MCP servers. MCP servers are still very new, and as the technology evolves, API Management provides an enterprise-ready solution that will evolve with the latest technology. Stay tuned for further feature announcements soon! Acknowledgments This post and work was made possible thanks to the hard work and dedication of our incredible team. Special thanks to Pranami Jhawar, Julia Kasper, Julia Muiruri, Annaji Sharma Ganti Jack Pa, Chaoyi Yuan and Alex Vieira for their invaluable contributions. Additional Resources MCP Client Server integration with APIM as AI gateway Blog Post: https://aka.ms/remote-mcp-apim-auth-blog Sequence Diagram: https://aka.ms/mcp-remote-apim-auth-diagram APIM lab: https://aka.ms/ai-gateway-lab-mcp-client-auth Python: https://aka.ms/mcp-remote-apim-auth .NET: https://aka.ms/mcp-remote-apim-auth-dotnet On-Behalf-Of Authorization: https://aka.ms/mcp-obo-sample 3rd Party APIs – Backend Auth via Credential Manager: Blog Post: https://aka.ms/remote-mcp-apim-lab-blog APIM lab: https://aka.ms/ai-gateway-lab-mcp YouTube Video: https://aka.ms/ai-gateway-lab-demoBuild. Secure. Launch Your Private MCP Registry with Azure API Center.
We are thrilled to embrace a new era in the world of MCP registries. As organizations increasingly build and consume MCP servers, the need for a secure, governed, robust and easily discoverable tools catalog has become critical. Today, we are excited to show you how to do just that with MCP Center, a live example demonstrating how Azure API Center (APIC) can serve as a private and enterprise-ready MCP registry. The registry puts your MCPs just one click away for developers, ensuring no setup fuss and a direct path to coding brilliance. Why a private registry? 🤔 Public OSS registries have been instrumental in driving growth and innovation across the MCP ecosystem. But as adoption scales, so does the need for tighter security, governance, and control, this is where private MCP registries step in. This is where Azure API Center steps in. Azure API Center offers a powerful and centralized approach to MCP discovery and governance across diverse teams and services within an organization. Let's delve into the key benefits of leveraging a private MCP registry with Azure API Center. Security and Trust: The Foundation of AI Adoption Review and Verification: Public registries, by their open nature, accept submissions from a wide range of developers. This can introduce risks from tools with limited security practices or even malicious intent. A private registry empowers your organization to thoroughly review and verify every MCP server before it becomes accessible to internal developers or AI agents (like Copilot Studio and AI Foundry). This eliminates the risk of introducing random, potentially vulnerable first or third-party tools into your ecosystem. Reduced Attack Surface: By controlling which MCP servers are accessible, organizations significantly shrink their potential attack surface. When your AI agents interact solely with known and secure internal tools, the likelihood of external attackers exploiting vulnerabilities in unvetted solutions is drastically reduced. Enterprise-Grade Authentication and Authorization: Private registries enable the enforcement of your existing robust enterprise authentication and authorization mechanisms (e.g., OAuth 2) across all MCP servers. Public registries, in contrast, may have varying or less stringent authentication requirements. Enforced AI Gateway Control (Azure API Management): Beyond vetting, a private registry enables organizations to route all MCP server traffic through an AI gateway such as Azure API Management. This ensures that every interaction, whether internal or external, adheres to strict security policies, including centralized authentication, authorization, rate limiting, and threat protection, creating a secure front for your AI services. Governance and Control: Navigating the AI Landscape with Confidence Centralized Oversight and "Single Source of Truth": A private registry provides a centralized "single source of truth" for all AI-related tools and data connections within your organization. This empowers comprehensive oversight of AI initiatives, clearly identifying ownership and accountability for each MCP server. Preventing "Shadow AI": Without a formal registry, individual teams might independently develop or integrate AI tools, leading to "shadow AI" – unmanaged and unmonitored AI deployments that can pose significant risks. A private registry encourages a standardized approach, bringing all AI tools under central governance and visibility. Tailored Tool Development: Organizations can develop and host MCP servers specifically tailored to their unique needs and requirements. This means optimized efficiency and utility, providing specialized tools you won't typically find in broader public registries. Simplified Integration and Accelerated Development: A well-managed private registry simplifies the discovery and integration of internal tools for your AI developers. This significantly accelerates the development and deployment of AI-powered applications, fostering innovation. Good news! Azure API Center can be created for free in any Azure subscription. You can find a detailed guide to help you get started: Inventory and Discover MCP Servers in Your API Center - Azure API Center Get involved 💡 Your remote MCP server can be discoverable on API Center’s MCP Discovery page today! Bring your MCP server and reach Azure customers! These Microsoft partners are shaping the future of the MCP ecosystem by making their remote MCP Servers discoverable via API Center’s MCP Discovery page. Early Partners: Atlassian – Connect to Jira and Confluence for issue tracking and documentation Box – Use Box to securely store, manage and share your photos, videos, and documents in the cloud Neon – Manage and query Neon Postgres databases with natural language Pipedream – Add 1000s of APIs with built-in authentication and 10,000+ tools to your AI assistant or agent - coming soon - Stripe – Payment processing and financial infrastructure tools If partners would like their remote MCP servers to be featured in our Discover Panel, reach out to us here: GitHub/mcp-center and comment under the following GitHub issue: MCP Server Onboarding Request Ready to Get Started? 🚀 Modernize your AI strategy and empower your teams with enhanced discovery, security, and governance of agentic tools. Now's the time to explore creating your own private enterprise MCP registry. Check out MCP Center, a public showcase demonstrating how you can build your own enterprise MCP registry - MCP Center - Build Your Own Enterprise MCP Registry - or go ahead and create your Azure API Center today!Introducing API Management Support in the Azure SRE Agent
In May, the Azure SRE Agent was introduced - an AI-powered Site Reliability Engineering (SRE) assistant built to help customers identify, diagnose, and resolve issues across their Azure environments faster and with less manual effort. Today, we’re excited to highlight how the SRE Agent now extends these capabilities to Azure API Management (APIM) , delivering deep operational visibility, guided troubleshooting, and intelligent remediation for customers running critical APIs at scale. API Management sits at the center of API application architectures, acting as a unified entry point for services, enforcing security, transforming requests, and routing traffic to backends. Ensuring the reliability of this layer is crucial - but as systems grow more distributed, it becomes harder to isolate failures, detect misconfigurations, or trace degraded performance to its root cause. The SRE Agent helps APIM users stay ahead of these challenges by providing both diagnostics and remediation tailored for API Management environments. You can ask the SRE agent direct API Management questions or concerns such as: “My API Management is giving me 503 errors” “We updated our policies yesterday, and now the backend is timing out.” “Can you help me figure out why requests to our billing API are failing?” “Show me recent changes to our APIM instance.” “What’s the failure rate on our orders operation this week?” Proactively Monitor API Management App Health The SRE Agent continuously monitors the overall health of your API Management service. It tracks key metrics such as CPU utilization, latency, error rates, and availability over time, surfacing any abnormal patterns and offering insight into capacity. This helps teams anticipate issues before they impact users and plan for scaling with confidence. Visualize Backend Connections and Health One of the most valuable APIM capabilities introduced with the agent is backend mapping. The agent can identify which backend services each API operation routes to, and visualize the health of those backends. This makes it much easier to answer operational questions like: “Which backend is responsible for the spike in errors on my /checkout API?” “Are there any timeouts happening from APIM to service X?” Drill into Backend App Issues If the root cause lies in a backend application - whether it's a service hosted in Azure Container Apps, Azure Functions Apps App Service, or another compute platform - the SRE Agent can go further. It analyzes backend-specific metrics such as memory and CPU usage, response time distribution, recent deployments, and any logged exceptions. The agent correlates this backend behavior with the observed degradation at the API Management layer to provide a full stack view of what’s happening. For example: “Your backend container app failed 37% of requests in the last hour due to out-of-memory errors. This correlated with a 5xx spike at the /stock/check API operation.” Detect and Fix Configuration Issues The SRE Agent also helps uncover common configuration issues that lead to downtime or silent failures, including: Malformed API policies Missing or misapplied network rules (NSGs, VNet) Incorrect scaling configuration or quota enforcement But it doesn’t stop at diagnostics. Where safe and possible, the agent can also perform remediation with your approval - for example, by adjusting NSG rules, scaling your API Management, etc. Built for Teams that Depend on APIM If API Management is critical to your infrastructure, the SRE Agent gives you an extra layer of confidence - offering the clarity and tooling needed to maintain uptime, reduce operational overhead, and catch issues before they escalate. The APIM-specific capabilities of SRE Agent are now available, and can be used in any SRE Agent resource (currently in preview). Signup for preview access We’re excited to bring this level of intelligence and automation to APIM, and we’re looking forward to your feedback as we continue to evolve the experience. Additional resources Azure SRE Agent overview (preview) | Microsoft Learn Introducing Azure SRE Agent | Microsoft Community Hub
Introduction and experience of Logic App Standard Advanced Tools – Part I
Scenario Microsoft announced General Availability (GA) of Logic App standard on 25th May 2021. We created an intelligent and efficient tool to self-troubleshoot Azure Logic App Standard. This tool integrated several useful features for Logic App Standard which are not available in Logic App portal yet. This blog introduces how to use this tool to help manage and troubleshoot logic app standard. This tool is still under development and this article will introduce some features so that it is Part I. We will have Part II and Part III in the future. Thanks! References GitHub - Drac-Zhang/Logic-App-STD-Advanced-Tools Services Used Azure Logic Apps (Standard) – Need Kudo Permission Introduction 1) Download tool: 2) Install tool: Just drag it into Kudo and it will install automatically: Help Page If you want to read Help Page first, please use this command LogicAppAdvancedTool -? (Main page of Help Page) LogicAppAdvancedTool [Command] -? (Introduction of each command) LogicAppAdvancedTool [Command] [Sub Command]-? (Introduction of each sub command) For example: Command format Please use command LogicAppAdvancedTool [Command] LogicAppAdvancedTool [Command] -wf [WorkflowName] For some other commands, they have sub-commands, eg. SyncToLocal: LogicAppAdvancedTool [Command] [SubCommand] Please note: Commands are case-insensitive. Command reference Backup: Retrieve all the definitions which can be found in Storage Table and save as Json files. The storage table saves the definition for the past 90 days by default even they have been deleted. Usage: Backup [options] Options: -d|--date (Optional) Retrieve workflow definitions which be modified/created later than this date (format: "yyyyMMdd"). -? Show help information. For example: CancelRuns: Cancel all the running/waiting instances of a workflow. Please note: Be aware of this command will cause data loss. Usage: CancelRuns [options] Options: -wf|--workflow (Mandatory) Workflow Name. -? Show help information. For example: CleanJobQueue: (Deprecated) Clear Logic App storage queue, this action could cause data loss. CleanUpContainers: Delete all the Logic App auto-generated blob containers for run history before a specific date. Usage: CleanUpContainers [options] Options: -wf|--workflow (Optional) The name of workflow. If not provided, then all the workflow containers will be deleted. -d|--date Delete containers before this date (format: "yyyyMMdd"), UTC time. -? Show help information. For example: CleanUpTables: Delete all the Logic App auto-generated storage tables for run history before a specific date. Usage: CleanUpTables [options] Options: -wf|--workflow (Optional) The name of workflow. If not provided, then all the workflow containers will be deleted. -d|--date (Mandatory) Delete run history related tables before this date (format: "yyyyMMdd"), UTC time. -? Show help information. For example: CleanUpRunHistory: Combined command of CleanUpContainers and CleanUpTables. Usage: CleanUpRunHistory [options] Options: -wf|--workflow (Optional) The name of workflow. If not provided, then all the workflow containers will be deleted. -d|--date (Mandatory) Delete run history related resources before this date (format: "yyyyMMdd"), UTC time. -? Show help information. For example: Check connectivity: Check the connection between Logic App and Storage Account via DNS resolution and TCP ping of 443 port. This command needs Kudu site is available. Usage: CheckConnectivity [options] Options: -? Show help information. For example: Clone: Clone a workflow to a new workflow, only support for same Logic App and same kind (stateful or stateless). Usage: Clone [options] Options: -sn|--sourcename (Mandatory) Source Workflow Name. -tn|--targetname (Mandatory) Target Workflow Name. -v|--version (Optional) Version of the workflow the latest version will be cloned, if not provided the latest version will be selected.) -? Show help information. For example: ConvertToStateful: Clone a stateless workflow and create a new stateful workflow. Usage: ConvertToStateful [options] Options: -sn|--sourcename (Mandatory) Source Workflow Name (Stateless) -tn|--targetname (Mandatory) Target Workflow Name (Stateful) -? Show help information. For example: Decode: Decode a workflow based on provided version to human readable content. Usage: Decode [options] Options: -wf|--workflow (Mandatory) Workflow Name. -v|--version (Mandatory) Version, the first part of the backup file name. -? Show help information. For example: GenerateTablePrefix: Generate Logic App/Workflow's storage table prefix. Usage: GenerateTablePrefix [options] Options: -wf|--workflow (Optional) Workflow name, if not provided, only Logic App prefix will be generated). -? Show help information. For example: GenerateRunHistoryUrl: Generate run history of failure runs of a specific workflow on a specific day. The url can directly open run history page. Usage: GenerateRunHistoryUrl [options] Options: -wf|--workflow (Mandatory) The name of workflow. -d|--date (Mandatory) The date (format: "yyyyMMdd") you would like to retrieve logs, UTC time. -f|--filter (Optional) Filter for specific exception messages. -? Show help information. For example: IngestWorkflow: (In development) This is an experimental feature. NOT fully tested, DON'T use in PROD environment!!! Ingest a workflow into Storage Table directly to bypass workflow definition validation. ListVersions: List all the existing versions of a workflow. Usage: ListVersions [options] Options: -wf|--workflow (Mandatory) Workflow Name. -? Show help information. For example: ListWorkflows: List all the existing workflows which can be found in the storage table. Usage: ListWorkflows [options] Options: -? Show help information. For example: RestoreAll: Restore all the workflows which were deleted accidentally. Please note: Restore all workflows which have been deleted, the existing workflows will not be impacted. Usage: RestoreAll [options] Options: -? Show help information. For example: RestoreSingleWorkflow: Restore a workflow which has been deleted accidentally. Usage: RestoreSingleWorkflow [options] Options: -wf|--workflow (Mandatory) The name of the workflow. -? Show help information. For example: RestoreRunHistory: Restore run history of a deleted/overwritten workflow. Please note: This is an experimental feature that might cause unexpected behavior in Logic App runtime since we directly modify workflow id. Usage: RestoreRunHistory [options] Options: -wf|--workflow (Mandatory) Workflow name. -? Show help information. For example: RetrieveFailures: Retrieve all the detailed failure information of a workflow for a specific day/run. Usage: RetrieveFailures [command] [options] Options: -? Show help information. Commands: Run 'RetrieveFailures [command] -?' for more information about command. Date Retrieve all the detailed failure information of a workflow for a specific day. Run Retrieve all the detail failure information of a workflow for a specific run. For example: Revert: Revert a workflow to a specific version. Usage: Revert [options] Options: -wf|--workflow (Mandatory) Workflow Name. -v|--version (Mandatory) Version, the first part of the backup file name. -? Show help information. For example: SyncToLocal: Sync remote wwwroot folder of Logic App Standard to local project. This command must run on a local computer. There are 3 subcommands for different usage, please use '-?' for more information. Please note: Local computers need to have access to Storage Account. Usage: SyncToLocal [command] [options] Options: -? Show help information. Commands: Run 'SyncToLocal [command] -?' for more information about a command. Auto Auto mode, there's no prompt dialog and can be set as schedule task for regular execution. Batch Batch mode, read configuration file (JSON format) from local folder and sync all the Logic Apps which are provided in config without prompt confirmation dialog. Normal Normal mode for manual sync, provides prompt dialog for confirmation of each step. For example: SearchInHistory: Search for a keyword in workflow run history based on date. Usage: SearchInHistory [options] Options: -wf|--workflow (Mandatory) The name of workflow. -d|--date (Mandatory) Date (format: "yyyyMMdd") of the logs need to be searched, UTC time. -k|--keyword (Mandatory) The keyword you would like to search for. -b|--includeBlob (Optional) true/false, whether needs to include the run history which saved as blob. Only the blob size less than 1MB will be checked due to memory saving. -of|--onlyFailures (Optional) Whether only to search for failed runs. -? Show help information. For example:Announcing Public Preview of Azure API Management Basic v2 and Standard v2 Tiers
We're thrilled to announce the public preview launch of our latest Azure API Management pricing tiers: Basic v2 and Standard v2. These new tiers address highly sought-after customer requests, bring quality-of-service enhancements, and offer a flexible starting point for API Management, allowing organizations of any size to embark on their API journey.Expose REST APIs as MCP servers with Azure API Management and API Center (now in preview)
As AI-powered agents and large language models (LLMs) become central to modern application experiences, developers and enterprises need seamless, secure ways to connect these models to real-world data and capabilities. Today, we’re excited to introduce two powerful preview capabilities in the Azure API Management Platform: Expose REST APIs in Azure API Management as remote Model Context Protocol (MCP) servers Discover and manage MCP servers using API Center as a centralized enterprise registry Together, these updates help customers securely operationalize APIs for AI workloads and improve how APIs are managed and shared across organizations. Unlocking the value of AI through secure API integration While LLMs are incredibly capable, they are stateless and isolated unless connected to external tools and systems. Model Context Protocol (MCP) is an open standard designed to bridge this gap by allowing agents to invoke tools—such as APIs—via a standardized, JSON-RPC-based interface. With this release, Azure empowers you to operationalize your APIs for AI integration—securely, observably, and at scale. 1. Expose REST APIs as MCP servers with Azure API Management An MCP server exposes selected API operations to AI clients over JSON-RPC via HTTP or Server-Sent Events (SSE). These operations, referred to as “tools,” can be invoked by AI agents through natural language prompts. With this new capability, you can expose your existing REST APIs in Azure API Management as MCP servers—without rebuilding or rehosting them. Addressing common challenges Before this capability, customers faced several challenges when implementing MCP support: Duplicating development efforts: Building MCP servers from scratch often led to unnecessary work when existing REST APIs already provided much of the needed functionality. Security concerns: Server trust: Malicious servers could impersonate trusted ones. Credential management: Self-hosted MCP implementations often had to manage sensitive credentials like OAuth tokens. Registry and discovery: Without a centralized registry, discovering and managing MCP tools was manual and fragmented, making it hard to scale securely across teams. API Management now addresses these concerns by serving as a managed, policy-enforced hosting surface for MCP tools—offering centralized control, observability, and security. Benefits of using Azure API Management with MCP By exposing MCP servers through Azure API Management, customers gain: Centralized governance for API access, authentication, and usage policies Secure connectivity using OAuth 2.0 and subscription keys Granular control over which API operations are exposed to AI agents as tools Built-in observability through APIM’s monitoring and diagnostics features How it works MCP servers: In your API Management instance navigate to MCP servers Choose an API: + Create a new MCP Server and select the REST API you wish to expose. Configure the MCP Server: Select the API operations you want to expose as tools. These can be all or a subset of your API’s methods. Test and Integrate: Use tools like MCP Inspector or Visual Studio Code (in agent mode) to connect, test, and invoke the tools from your AI host. Getting started and availability This feature is now in public preview and being gradually rolled out to early access customers. To use the MCP server capability in Azure API Management: Prerequisites Your APIM instance must be on a SKUv1 tier: Premium, Standard, or Basic Your service must be enrolled in the AI Gateway early update group (activation may take up to 2 hours) Use the Azure Portal with feature flag: ➤ Append ?Microsoft_Azure_ApiManagement=mcp to your portal URL to access the MCP server configuration experience Note: Support for SKUv2 and broader availability will follow in upcoming updates. Full setup instructions and test guidance can be found via aka.ms/apimdocs/exportmcp. 2. Centralized MCP registry and discovery with Azure API Center As enterprises adopt MCP servers at scale, the need for a centralized, governed registry becomes critical. Azure API Center now provides this capability—serving as a single, enterprise-grade system of record for managing MCP endpoints. With API Center, teams can: Maintain a comprehensive inventory of MCP servers. Track version history, ownership, and metadata. Enforce governance policies across environments. Simplify compliance and reduce operational overhead. API Center also addresses enterprise-grade security by allowing administrators to define who can discover, access, and consume specific MCP servers—ensuring only authorized users can interact with sensitive tools. To support developer adoption, API Center includes: Semantic search and a modern discovery UI. Easy filtering based on capabilities, metadata, and usage context. Tight integration with Copilot Studio and GitHub Copilot, enabling developers to use MCP tools directly within their coding workflows. These capabilities reduce duplication, streamline workflows, and help teams securely scale MCP usage across the organization. Getting started This feature is now in preview and accessible to customers: https://aka.ms/apicenter/docs/mcp AI Gateway Lab | MCP Registry 3. What’s next These new previews are just the beginning. We're already working on: Azure API Management (APIM) Passthrough MCP server support We’re enabling APIM to act as a transparent proxy between your APIs and AI agents—no custom server logic needed. This will simplify onboarding and reduce operational overhead. Azure API Center (APIC) Deeper integration with Copilot Studio and VS Code Today, developers must perform manual steps to surface API Center data in Copilot workflows. We’re working to make this experience more visual and seamless, allowing developers to discover and consume MCP servers directly from familiar tools like VS Code and Copilot Studio. For questions or feedback, reach out to your Microsoft account team or visit: Azure API Management documentation Azure API Center documentation — The Azure API Management & API Center TeamsChoosing the right Azure API Management tier for your networking scenarios
There are different options when it comes to integrating your API Management with your Azure Virtual Network (VNet) which are important to understand. These options will depend on your network perimeter access requirements and the available tiers and features in Azure API Management. This blog post aims to guide you through the different options available on both the classic tiers and v2 tiers of Azure API Management, to help you decide which choice works best for your requirements. We need to define how are we going to call the tiers : developer, basic, standard , premium. For example v1 tiers, classical tiers, etc…Announcing the Public Preview of the Applications feature in Azure API management
API Management now supports built-in OAuth 2.0 application-based access to product APIs using the client credentials flow. This feature allows API managers to register Microsoft Entra ID applications, streamlining secure API access for developers through OAuth 2.0 authorization. API publishers and developers can now more effectively manage client identity, access, and authorization flows. With this feature: API managers can identify which products require OAuth authorization by setting a product property to enable application-based access API managers can create and manage client applications and assign them access to specific products. Developers can see their registered applications in API management developer portal and use OAuth tokens to securely call APIs and products OAuth tokens presented in API requests are validated by the API Management gateway to authorize access to the product's APIs. This feature simplifies identity and access management in API programs, enabling a more secure and scalable approach to API consumption. Enable OAuth authorization API managers can now identify specific products which are protected by Microsoft Entra identity by enabling "Application based access". This ensures that only valid client applications which have a secure OAuth token from Microsoft Entra identity can access the APIs associated with this product. An application is created in Microsoft Entra corresponding to the product, with appropriate app role. Register client applications and assign products API managers can register client applications, identify specific developers as owners of these applications and assign products to these applications. This creates a new application in Microsoft Entra and assigns API permissions to access the product. Securely access the API using client applications Developers can login into API management developer portal and see the appropriate applications assigned to them. They can retrieve the application credentials and call Microsoft Entra to get an OAuth token, use this token to call APIM gateway and securely access the product/API. Preview limitations The public preview of the Applications is a limited-access feature. To participate in the preview and enable Applications in your APIM service instance, you must complete a request form. The Azure API Management team will review your request and respond via email within five business days. Learn more Securely access product APIs with Microsoft Entra applications
