ai
81 Topicsπ Automation just became a team sport. Meet Azure Logic Apps Automation.
Low barrier to entry. Built for production. Now in Public Preview There's a moment that plays out in almost every organization right now. Someone closest a business problem - a retail ops lead, a finance analyst, a security analyst looks at a repetitive process and thinks, this should just run itself. For most of computing history, turning that idea into reality required specialized skills, significant setup, and engineering resources that were often focused elsewhere. AI is changing that. Today, people can describe what they want in natural language and watch working solutions take shape. The bottleneck is no longer generating an idea for automation. It's turning that idea into something secure, governed, and reliable enough to run in production. The demos are everywhere. The question organizations are increasingly asking is the harder one: which of these can we actually run in production? That's exactly the shift we built for. Today at Microsoft Build we're introducing Azure Logic Apps Automation, a new Logic Apps SKU that delivers the experience of a modern SaaS product for creating and running workflow automations. It makes it easier for teams to get started quickly while preserving the security, governance, reliability, and scale organizations expect from Azure. It's open to builders of every kind, available now in public preview at https://auto.azure.com. New experience, same enterprise engine The goal was straightforward: simplify the experience of building and running automations without compromising the enterprise foundation underneath. Logic Apps Automation provides a managed experience where compute, model endpoints, knowledge services, and execution environments are available out of the box. Teams can focus on solving business problems rather than assembling infrastructure and services. We also introduced a dedicated SaaS experience designed around productivity and collaboration. Administrators establish governance and policies, while builders can quickly begin creating workflows without requiring deep Azure expertise. "The redesigned experience lets me build AI-based solutions in record time. This platform will serve as the glue in most modern solutions.", Mick Badran, Founder & Director at SolveIT.Today [LA Automation Early Adopter] What we kept is just as important. Logic Apps Automation is built on the same Azure Logic Apps platform organizations trust today. The reliability, scale, security, governance, and operational maturity remain the foundation. The experience is simpler, but the platform underneath is the same proven technology customers rely on every day. Low barrier to entry. Built for production. We mean both halves of that sentence. Build like a startup, ship like an enterprise Building an automation is only part of the full application journey. As solutions move from experimentation to production, along with simple experience, organizations need security, governance, networking, identity, and operational controls to ensure those automations can be trusted at scale.Logic Apps Automation is designed for both realities. On the build side, it's fast to get started. Login and start building workflows; stay on a single canvas throughout the experience: use AI assisted workflow development, use visual workflows when theyβre the right fit, and drop into code the moment you need additional control. No switching tools, no handoffs, no separate infrastructure to manage. On the production side, organizations get the capabilities they expect from an enterprise platform, on day-0: isolated compute, virtual network integration and private endpoints, identity, role-based access, audit logging, and governance policies. For many automation tools, becoming "enterprise-ready" is something that happens later. With Logic Apps Automation , production-readiness is part of the foundation. Built for how teams actually work Making automation easier for builders shouldn't create additional complexity for administrators. Organizations already have established governance boundaries, ownership models, and operational processes. Logic Apps Automation is designed to align with those realities through a simple two-level hierarchy of Projects and Applications. Project sits at the top and act as your security and governance boundary; inside each project you run one or more Applications. Admins and project owners set networking policies, connector policies, sandbox configuration, and approved AI models once, at the project scope and every application inherits them. Builders get a wide-open space to create. Admins get a firm line around it. Nobody has to choose between the two. Flexible permission management for individuals and teams The permission model is also designed to match how teams collaborate: A private space for an individual. To give a single user a place to run their own automations with a privacy boundary around personal resources such as their email account - create an application that only that individual can access. A shared space for a team. To support an automation that several people co-develop and operate together, add multiple users to the application so they can build, run, and maintain it collectively. The same model accommodates both access patterns, giving builders clear control over the scope of each application and who can work within it. AI-native, not AI-retrofitted Logic Apps Automation is designed for a new generation of business processes that combine workflows, AI agents, enterprise systems, and human decision-making. It starts with how you build. A built-in AI Assistant turns plain language into working automation. You describe what you want and it drafts the workflow, configures actions, writes expressions, and generates inline code, then helps you edit the same way. You can author at the level of a single step or an entire end-to-end flow. This is the thing that opens the platform to *every* developer: the person closest to the problem can describe it and get something real, while pros stay in control and drop to code whenever they want. "With the power of AI, automations just got on steroids! Simply tell it what you need, explain the intent, et voilΓ ! Love it.", Sonny Gillissen, Integration Architect at Rubicon Cloud Advisor [LA Automation Early Adopter] Agents are first-class Agents are first-class, and we meet you where you are with three ways to integrate them: Agent-loop orchestration. If you're already using Logic Apps actions as tools inside an agent loop, that pattern carries forward. Your actions are callable tools the agent can invoke, so you keep orchestrating the way you always have. Foundry agents. Connect to an existing Microsoft Foundry Hosted or Prompt Agent or create a new one right from the canvas. The platform handles the wiring, and your workflow calls the agent, gets results back, and keeps moving. Managed sandbox for agent harnesses. Bring a well-known agent harness, like GitHub Copilot and run it in a managed, isolated sandbox. We take care of the compute, the isolation, native shell access, and your GitHub repos as first-class context; you just define the business logic. Then orchestrate all of these inside a larger workflow, right next to traditional rule-based actions, on a single canvas. Deterministic and agentic, in one place. A few capabilities that make this especially powerful: Sandboxed agent harnesses. Run agent harnesses such as GitHub Copilot in a managed, isolated sandbox with shell execution, skills, and GitHub repos as first-class context, without operating any of that infrastructure yourself. Tools and MCP. Turn any of the 1400+ connectors into a tool or expose any workflow as an MCP server that any compatible agent can call. No code required. Knowledge as a Service. Drop in your documents and the platform handles ingestion, chunking, embeddings, and retrieval. No RAG pipeline to build, no vector store to operate; just grounded answers. Any model, anywhere. Plug in whatever fits the job: frontier, open-source, fine-tuned, or local. You're never locked in. "Azure Automation closes the gap between integration and intelligence with agents as first-class workflow actions, grounded in your own data, executing in isolated sandboxes, all within the same canvas where your triggers and connectors live. Excited to see the evolution.", Sagar Sharma, Enterprise Solution Architect at i8c NL [LA Automation Early Adopter] What's new in this release Logic Apps Automation introduces several new capabilities designed to help teams build, deploy, and govern AI-powered automations: Zero-friction onboarding. Get from Sign-in to first workflow in minutes, with managed infrastructure and enterprise capabilities available from the start. A new designer. Modern designer with single pane experience to build and monitor workflows, draft-mode for workflows for easy iterations, instant code-to-workflow synchronization when you want to work in code-view, run history you can stream live, and so much more Natural language authoring. Describe workflows in plain language to create and edit them, with AI assistance in the designer. More powerful agents. Three ways to bring agents into a workflow; agent-loop orchestration, Foundry Hosted Agents, and well-known harnesses like GitHub Copilot running in a managed, isolated sandbox with shell access and GitHub repos as context. Knowledge as a Service. A managed knowledge layer that turns your documents into a ready-to-use knowledge base; no RAG pipeline required. JavaScript expressions. Write inline JavaScript to transform data and express logic without leaving the designer; no domain-specific language to learn. Projects and applications. A two-level governance hierarchy that gives admins a clear boundary and builders room to create. A permission management model that accommodates different level of access patterns, giving builders clear control over the scope of each application and who can work within it. Elastic scale, including to zero. Workflows scale up automatically when load arrives and scale all the way down to zero when there's no work to do. You pay only for the vCPU-seconds you actually use. Built to scale Logic Apps Automation scales automatically with demand, from idle workloads to business-critical processes. Customers pay only for the resources they use, without per-seat licensing requirements or infrastructure management overhead. When workflows aren't running, you're not paying for compute. When demand increases, the platform scales with you. Pricing Logic Apps Automation uses a consumption-based pricing model, so you pay only for what you use. Pricing is based on a small managed-environment fee, workflow execution, and optional services such as AI model usage, knowledge, sandboxes, connector calls. There is no annual commitment, no per-seat license, no quota cliff. When your workflows sit idle, you pay nothing for compute. More details to follow soon. What's available, and what's next Logic Apps Automation is available today in public preview, with an intial set of regions today, with more rolling out over the coming weeks. Here is the list of regions its available today: East Asia Sweden Central Australia East North Central US UK South Southeast Asia West US Coming Soon We're continuing to expand the platform with additional AI and enterprise capabilities, including: Foundry Hosted Agents. Create or Invoke Foundry Hosted Agents directly inside your workflows. Foundry Prompt Agents. Create/Invoke Foundry prompt directly inside your workflows. Hosted Models. Managed model endpoints provided for you; no keys or infrastructure to bring. Inline Python. Write inline Python alongside JavaScript when you need it. Bring your own container image. Run your own code in sandboxes; for example, orchestrate a Python ETL job from within a Logic Apps workflow. VNet support and private endpoints. Custom connectors and more Automation templates. Build custom connectors, start from a growing library of templates, and set project-level policies on connectors and more. Get started Whether you're automating a business process, orchestrating AI agents, integrating enterprise systems, or building entirely new AI-powered experiences, Logic Apps Automation provides a simpler path from idea to production. Start building today at https://auto.azure.com Read the docs at http://auto.azure.com/docs Watch the announcement session at Microsoft Build 2026. See it live at the Integrate conference, June 8β9.1.3KViews0likes1Commentπ’ Announcing Knowledge as a Service for Azure Logic Apps
Now in Public Preview Turn your documents into a ready-to-use knowledge base without custom RAG pipelines. Today at Microsoft Build 2026, we are announcing the Public Preview of Knowledge as a Service for Azure Logic Apps. It is a managed knowledge layer that transforms your documents into a ready-to-use knowledge base, removing the need to build custom Retrieval-Augmented Generation (RAG) pipeline, operate a vector store, or maintain retrieval logic. The result is grounded, accurate answers for the agents and workflows you are building today. Most organizations hold a significant amount of institutional knowledge such as HR policies, product manuals, support runbooks, contracts, and specifications distributed across documents, spreadsheets, and internal systems. The challenge has rarely been the availability of content. It has been making that content reliably and accurately retrievable by AI agents and workflows. Until now, addressing this challenge required building a RAG pipeline in-house. As any team that has implemented one can attest, a production-grade RAG pipeline involves substantial engineering effort and ongoing operational overhead. The complexity of building RAG in-house A production-grade RAG pipeline is not a single component. It is a set of interdependent systems that must be designed, integrated, and maintained: Ingestion: parsing multiple file formats, chunking content appropriately, summarizing, and generating embeddings. Storage: provisioning a vector database, defining indexing policies, and tuning for cost and performance. Retrieval: rewriting queries, vectorizing them, executing semantic search, and returning the most relevant chunks to the model. Operations: monitoring upload status, handling failures, managing credentials, and maintaining security. Each component represents a meaningful engineering investment. Together, they constitute a platform β one that diverts engineering capacity away from the business problems teams set out to solve. Introducing Knowledge as a Service Knowledge as a Service (also referred to as Knowledge Base as a Service, or KBaaS) is a managed knowledge layer built into Azure Logic Apps that turns your documents into a ready-to-use knowledge base, without requiring you to build or operate a RAG pipeline. You provide the documents, and the platform manages the remainder of the process, both ingestion and retrieval, end to end. Built directly into Logic Apps, KBaaS provides an abstraction over the underlying vector store and AI models, enabling your workflows to consume structured, semantically searchable knowledge through a single connection. A knowledge base is a logical container that organizes related sources for a given domain. For example, an "HR Policies" knowledge base might hold all relevant HR documents. You create the knowledge base, upload your files, and attach it as a tool that your agent can call. How it works KBaaS is built around two managed pipelines. Ingestion pipeline. When you upload a knowledge source, the service automatically parses, chunks, summarizes, and vectorizes the content, then stores the results, with no manual preprocessing required. The current preview supports a broad range of formats out of the box: DOC, DOCX, HTML, MD, PDF, PPT, PPTX, TXT, XLS, and XLSX. Each upload provides a progress status and a clear Completed or Failed result. Retrieval pipeline. When your agent queries the knowledge base, the service rewrites the query where beneficial, generates a vector representation, executes a semantic search, and returns the most relevant chunks to the language model for response generation. Query planning, vector search, and ranking are all handled by the service. The outcome is that your agents receive accurate, context-rich answers grounded in your own content, without requiring you to author retrieval logic. Built for agentic workflows KBaaS is available in Azure Logic Apps Standard, where it integrates directly with agentic workflows. Once a knowledge base has been created, it appears as a capability that can be attached to an agent loop. From there, the agent automatically queries the knowledge base to retrieve semantically relevant information from your uploaded documents at the point it is needed, as part of completing a task. Getting started involves three steps: Create the knowledge base connection - associate your vector store and your completions and embeddings models. Add knowledge sources - upload files into a knowledge base, optionally organized into groups. Add the knowledge base as a context - select it from the agent node so your agent can begin retrieving. The platform provisions and manages the required databases, containers, and indexing policies on your behalf, removing the burden of operating the underlying storage and search infrastructure. Two SKUs to consume it - Standard or Automation This feature is available across Logic Apps SKUs, with some differences in how you setup and manage them. Logic Apps Standard β bring your own resources. On Standard SKU, the model operates on your own Cosmos DB vector store and AI models, KBaaS integrates with them directly. You connect your existing resources, and the platform manages the complete ingestion and retrieval pipeline on top of them. This approach retains full control over your data and models while removing the need to build and maintain the RAG pipeline. Logic Apps Automation SKU β bring only your documents. On the Automation SKU, KBaaS operates on a hosted-on-behalf-of model, in which the platform provisions and manages both the underlying vector store and the AI models. There is no Cosmos DB to provision, no embeddings or completions model to deploy, and no connections to configure. You upload your documents and attach the knowledge base to your agent, and the entire knowledge layer, including the supporting infrastructure is fully managed for you. This delivers the same managed knowledge experience with the maximum degree of abstraction, providing the most direct path from source documents to a working, agent-ready knowledge base. Secure by design KBaaS supports authentication through Microsoft Entra ID using either a managed identity or an API key. We recommend managed identity wherever possible. It is the most secure option and eliminates the need to manually provision and rotate credentials, secrets, or access keys. Available today in Public Preview This initial release focuses on the most common starting point: uploading unstructured documents. Additional capabilities are planned, including support for more knowledge sources, richer ingestion (such as image parsing, semantic chunking, and multimodal embeddings), configurable retrieval settings, access checks during retrieval, and more. Knowledge as a Service is available now in Public Preview. Provide your documents and give your agents a knowledge base that is ready to use, without building or operating a RAG pipeline. Read the MS Learn docs to get started Check out the demo below2.1KViews1like0CommentsNew AI gateway capabilities in Azure API Management
Multi-model, multi-protocol AI applications are quickly becoming the norm. Teams are mixing OpenAI, Anthropic, and Vertex AI models, exposing tools through MCP, and wiring agents together with A2A. As that surface grows, so does the work of keeping it secure, observable, and consistent. Our ongoing strategy for the AI gateway capabilities in Azure API Management centers on that problem: providing one place to manage models, MCP tools, and agents, no matter which provider or protocol is behind them. The updates below are the latest steps in that direction. Unified Model API (preview) The headline change in this release: the Unified Model API lets clients speak one API format β OpenAI Chat Completions β while API Management transforms requests to the backend provider, whether that's a model using OpenAI Chat Completions or Anthropic Messages API. By centralizing model access behind a single API layer, you can: Standardize on a single API format for clients, independently from the formats used by backend models. Unify observability, security, and governance with policies that apply across model providers. Configure failover across model providers. Decouple client-facing model names from backend model names using aliases. Learn more about the unified model API. Model aliases Model aliases give clients a stable, provider-neutral name to use when calling a model. By assigning an alias like gpt or claude-sonnet, you decouple the client-facing model name from the actual backend deployment. That makes a few common operations a lot easier: Upgrading a model. Update the alias target to point at a new version β no client code changes required. A/B tests. Shift traffic between backends behind the same alias using API Management's load balancing capabilities. Vendor swaps. Replace one provider with another without touching application code. Model discovery Developers can discover available models by calling the /models endpoint of the Unified Model API. API Management returns the list of model aliases, so apps and tools can adapt to what the platform team has published β without out-of-band documentation. Anthropic and Vertex AI models (GA) AI gateway policies and observability now work with Anthropic and Google Vertex AI models, alongside the providers we already support. You can: Apply runtime policies such as content safety, token limits, and semantic caching to Anthropic and Vertex AI traffic. Collect logs, traces, and metrics for these models in the same place as the rest of your AI traffic. If you're running a multi-provider setup, you no longer need a separate governance story for each vendor. Learn more about AI gateway capabilities in API Management. Anthropic API operations in Microsoft Foundry import When you import a Microsoft Foundry resource as an API in Azure API Management, the import now creates operations for Anthropic APIs alongside the existing model APIs. In a few clicks, you can stand up an API that mediates traffic to Foundry models using either the OpenAI or Anthropic API format β no manual operation definitions needed β and then apply the same policies, security, and observability you use for the rest of your AI traffic. Learn more about Microsoft Foundry import. Token metrics for additional token types (preview) Token tracking used to stop at prompt, completion, and total tokens. Modern models add cached, reasoning, and thinking tokens, which can make up a significant share of token consumption, cost, and latency. API Management now logs metrics for these additional token types into Application Insights, across API formats (OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages API) and providers (Microsoft Foundry, OpenAI, Amazon Bedrock, Google Vertex AI, and others). With richer signals, your cost dashboards, budget alerts, and capacity planning can actually reflect how today's models behave. Learn more about token metrics. Content safety for MCP and A2A (GA) The llm-content-safety policy now covers MCP and A2A traffic in addition to LLM traffic. That includes MCP tool-call arguments, MCP response text, and A2A payloads. A couple of related improvements: llm-content-safety can now be configured directly as an outbound policy. Two new attributes β window-size and window-overlap-size β let you tune how messages exceeding the Azure Content Safety limit of 10,000 characters are chunked and forwarded for validation, balancing detection sensitivity with Azure Content Safety call volume. The result is one consistent safety policy across LLM, MCP, and A2A flows instead of stitching together custom filters per protocol. Learn more about the content safety policy. A2A APIs (GA) Support for Agent-to-Agent (A2A) APIs in API Management is now generally available. Agent APIs can now be governed with the same policies, identity, and observability you use for the rest of your APIs. What you can do with A2A APIs in API Management: Mediate JSON-RPC runtime operations to your agent backend with full policy support β including the content safety improvements above. Expose and manage agent cards, automatically transformed by API Management to represent the managed agent API. Log traces to Application Insights using OpenTelemetry GenAI semantic conventions for deep correlation between API and agent execution traces. What's new in GA, on top of the preview: Available in classic tiers, in addition to v2 tiers β bring A2A governance to existing API Management resources without migrating tiers. Richer diagnostic logging for A2A APIs, giving more actionable telemetry for monitoring and troubleshooting agent traffic. Learn more about A2A support in API Management. Related: Bring Your Own Model in Foundry Agent Service (GA) Last month, Bring Your Own Model (BYOM) in Foundry Agent Service went GA. BYOM lets enterprise teams route Foundry agent model calls through their own infrastructure β typically for compliance, governance, or to reuse an existing model gateway. This pairs naturally with the AI gateway capabilities in Azure API Management. Put API Management in front of your models, apply the policies and observability described above, and have Foundry agents call through it β getting consistent governance for both your direct AI traffic and your agent workloads. Get started Together, these updates make Azure API Management a more complete AI gateway: consistent governance, security, and observability across models from various providers, MCP tools, and agent interactions. Some of these features are still rolling out. They will first become available in v2 tiers of API Management and in the AI release channel for classic tiers, then continue rolling out to the rest of classic tier resources over the following weeks. Get started with the unified model API or explore the AI gateway capabilities in API Management.358Views0likes0CommentsBetter Together: Build Agents in Microsoft Foundry, Automate them with Azure Logic Apps
One agentic stack: Foundry brings the intelligence; Logic Apps brings the automation and orchestration. The promise of agentic AI is not simply more capable chat. It is autonomous work that advances real business processes. To achieve this, agents require two things: a place to be built with the appropriate models, instructions, knowledge, and guardrails and a place to be invoked and orchestrated, with triggers, workflows, and connections to the systems where work actually occurs. Today, we are announcing a significantly improved experience that brings these two platforms together: Microsoft Foundry and Azure Logic Apps. Together, they form a single agentic stack. Foundry provides the intelligence, and Logic Apps provides the automation and orchestration. What's new This release introduces a set of updates that taken together, brings a really better together experience to build and automate AI A streamlined experience to create and invoke Foundry Agents from Azure Logic Apps. You can now move from having an agent to running that agent inside a production business workflow in a few steps. You can author, configure, and call a Foundry Agent directly from the Logic Apps designer, with no custom integration code required. Run Foundry Agents autonomously with Logic Apps triggers. This capability is what enables embedding Foundry Agents in workflows. A chat-bound agent runs only when a user types a message; an autonomous agent runs when the business requires it. With this release, you can pair any Logic Apps trigger with a Foundry Agent to build a business process, automating agents to react to events, run on a schedule, or both. These triggers can come from any of the 1,400+ connectors that expose them β such as ServiceNow incidents, GitHub issues, Jira tickets, and SAP IDocs β each capable of initiating a Foundry Agent. The result is that your agents do not wait for someone to interact with them. They activate the moment work arrives, reason about it, take action through their tools, and, where appropriate, hand off to long-running workflows. Logic Apps connectors are now available as tools for Foundry Agents. Any of those same 1,400+ Azure Logic Apps connectors can now be exposed directly to a Foundry Agent as a native tool. An agent can reason about a customer issue and then update the CRM, file the ticket, send the approval, or post the message. Invoke entire workflows, including long-running ones, as Foundry agent tools. Tools are not limited to a single API call. With Logic Apps, an agent can invoke an entire workflow as a tool: a multi-step approval that waits days for a human response, a webhook callback, a long-running orchestration spanning multiple systems, or a process that pauses and resumes on external events. The agent reasons, and the workflow executes durably for as long as the process requires. Business process automation, durable workflows, and agentic AI are now available on the same stack. Why this matters Building automations with agents and deterministic logic has meant working across two separate worlds: one platform to build and host the agent, and another to connect it to the systems where work happens and to invoke it when needed. This release brings those two worlds together. Foundry and Logic Apps now work as one agentic stack, with each platform handling what it does best Azure AI Foundry β Where agents are built and hosted Azure Logic Apps β Where agents are invoked and orchestrated Define agents with models, instructions, and tools Trigger agents from any event, on any schedule Ground responses in knowledge and enterprise data Orchestrate multi-step, multi-agent business processes Evaluate, version, and observe agent behavior Expose 1,400+ connectors, workflows, MCPs, webhooks, and agents as native tools Getting Started If you already have a Foundry Agent and a Logic Apps environment, you're a few clicks away. Here are the steps to Create and/or Invoke Foundry Agents from Logic Apps Workflows Add an Agent node to your workflow: In the Logic Apps designer, add the Agent node to your workflow. Creation connection: If you don't already have a connection, you'll be prompted to create one. Make sure it's a Foundry Project connection: select Foundry Project from the Agent Model Source drop-down, then provide your project endpoint and API key. Invoke an existing Foundry agent: Once the Agent node is added, pick an agent from the Agent drop-down. Logic Apps defaults to the latest version and shows the agent's configured model and instructions. You can invoke the agent as-is, or make changes from the designer, including adding Logic Apps tools to the Foundry Agent. Or create a new agent: To create a new agent from the designer, provide an Agent Name and Model, then choose Create; the agent is created in Foundry. You can optionally add Instructions and Logic Apps tools before saving. Configure Agent: When you choose to create a new agent, you add the Agent Name and Model and that allows you to Create that agent in Foundry. Optionally you can add Instructions and Logic Apps tools from the designer. The Agent is Created when you click on Create. You can invoke from Logic Apps or from Foundry portal as well. Add tools: Logic Apps tools are how your agent takes action. A tool can include not just 1400 connectors, but also MCPs, workflows, custom code, Agents or APIs Closing Agents are only useful when they can act - and act autonomously, durably, and across the systems and timeframes that real business processes require. With Microsoft Foundry providing the agent platform, and Azure Logic Apps providing the triggers, workflows, connectors, webhooks, and agent-as-tool composition, AI capability turns into automated business processes.157Views0likes0CommentsMCP Test Console and Git Repository synch in Azure API Center
Why This Matters As organizations race to build AI-powered applications, the Model Context Protocol (MCP) has emerged as the standard way to connect AI agents with external tools and data sources. Managing these MCP servers at enterprise scale, however, has been a growing challenge β until now. AI agents are only as useful as the tools they can access. MCP servers expose those tools β from databases and internal APIs to third-party services β in a standardized way that any AI agent or model can consume. As your MCP ecosystem grows, so does the challenge of keeping track of what's available, what's working, and what your teams are actually using. Azure API Center already serves as a centralized registry for APIs across your organization. Now it extends that same governance model to MCP servers, complete with developer-friendly discovery, live testing, and automated synchronization from your source repositories. New Feature: MCP Test Console in the API Center Portal Developers can now test MCP server tools interactively without leaving the Azure portal. Once an MCP server is registered in your API Center inventory, the API Center portal β your organization's customizable developer portal β surfaces a dedicated test console on the server's Documentation tab. Developers simply select a tool, click Run tool, and immediately see the response. This means your teams can: Validate tools before connecting them to agents β no more building a test harness from scratch. Explore tool schemas interactively β the portal surfaces endpoint details and input/output schemas alongside the live console. Onboard faster β developers browsing your internal MCP registry can go from discovery to verified integration in minutes. The MCP server tiles in the portal provide a clear, browsable view of all registered servers. Each tile surfaces the server's endpoint URL, available tools, and installation instructions for Visual Studio Code β giving developers everything they need to get started in one place. Getting started: Set up your API Center portal, then navigate to any registered MCP server. On the Documentation tab, select a tool and click Run tool to open the test console. New Feature: Synch MCP Servers from a Git Repository Managing API assets shouldn't require manual registration every time something changes. With Git repository integration, Azure API Center can automatically sync assets β including MCP server definitions β directly from your source repository. How It Works When you connect a Git repository to your API Center: An environment is created in your API Center representing the repository as an asset source. API Center regularly synchronizes MCP servers from the repository into your inventory β no manual intervention required. Assets appear in your inventory on the Inventory > Assets page with a visual link indicator, making it easy to identify which assets are source-controlled. This is especially valuable for teams that maintain MCP server definitions, skill files, or OpenAPI specs in version control. As your repository evolves, your API Center inventory stays current automatically. Setting It Up Step 1: Secure your access credentials (for private repos) If your repository is private, store a personal access token (PAT) as a secret in Azure Key Vault. Your API Center instance uses a managed identity to retrieve this secret securely β you can configure the managed identity manually or let API Center handle it automatically during the integration setup. Step 2: Connect the repository In the Azure portal, go to your API Center and navigate to Platforms > Integrations > + New integration > From Git repository. You'll configure: Repository URL β including an optional branch and subfolder path (e.g., https://github.com/<org>/<repo>/tree/main/skills). Git provider β such as GitHub. Asset type configuration β API Center defaults to a skill asset type with the file pattern **/skill.md, but you can add additional asset types to match your repository structure. PAT reference β select the Key Vault secret containing your PAT, if applicable. Environment details β give the repository environment a friendly name, resource ID, type (e.g., Production), and lifecycle stage for synced assets. Step 3: Let the sync run Once created, the integration runs automatically. Your assets will appear in the Inventory > Assets view, linked to their source in the repository. Access Control for Private Repositories The integration uses Azure's managed identity framework to authenticate to Key Vault. Assign your API Center's managed identity the Key Vault Secrets User role on your Key Vault to grant the necessary read access. If you prefer, API Center can configure this automatically β just enable the Automatically configure managed identity and assign permissions option during integration setup. Bringing It Together: A Complete MCP Governance Story Together, these two features complete an end-to-end workflow for enterprise MCP governance: Register β Connect your Git repository and let API Center automatically synch your MCP servers and skills as they evolve. Discover β Developers and AI engineers browse the API Center portal to find the right MCP server for their agent, with full schema visibility and endpoint details. Test β The built-in test console lets developers validate tools interactively before committing to an integration. Govern β Use API Center's access management capabilities to control who can view and consume specific MCP servers across your organization. And if you're building MCP servers on Azure services, the registry integrates directly with Azure API Management, Azure Logic Apps, and Azure Functions β so your MCP ecosystem and your API ecosystem share a single source of truth. Get Started Register and discover MCP servers in Azure API Center Synchronize API assets from a Git repository Set up the API Center portal Explore MCP Center β Azure API Center's public MCP registryMore Control, Less Overhead: Custom Domain Upgrades in Azure API Management v2
Multiple custom domains in Premium v2 Large organizations rarely expose APIs under a single domain. A global enterprise might need api.contoso.com for external partners, apis.hrportal.contoso.com for internal teams, and dev.europe.contoso.com for a regional developer portal β all at once. Until now, achieving this required spinning up separate API Management instances, adding cost and operational complexity. Azure API Management Premium v2 now supports multiple custom domains within a single instance β across gateway, developer portal, and management endpoints. This allows organizations to: Configure distinct hostnames for different endpoints and target audiences Align API experiences with business units, products, or regional brands Simplify domain-scoped networking and security policies Reduce the need for separate APIM instances created solely for domain separation For enterprises managing large, distributed API estates, this provides greater flexibility in how APIs and developer experiences are exposed β while maintaining centralized governance. Wildcard custom hostnames in Premium v2 and Standard v2 As API estates grow, managing individual certificates for every subdomain becomes a scaling problem fast. Each new surface β payments.api.contoso.com, inventory.api.contoso.com, orders.api.contoso.com β previously required its own hostname registration and certificate. Ten new API surfaces meant ten separate management tasks. Azure API Management Premium v2 and Standard v2 now support wildcard entries in custom hostnames. A single *.api.contoso.com entry paired with a single wildcard certificate covers all subdomains automatically β no per-subdomain configuration required. This helps teams: Simplify certificate and domain management at scale Accelerate onboarding of new API surfaces without repeated hostname setup Maintain consistent branded endpoints across dynamic subdomains Reduce operational overhead for rapidly growing API environments By extending this capability to both Premium v2 and Standard v2, Azure API Management makes flexible, scalable domain management accessible to more organizations without requiring higher-tier deployments. Both updates are generally available now. Learn more about Azure API Management v2 tiers and how they help organizations build scalable, enterprise-grade API platforms. Further reading: Configure a custom domain name for Azure API ManagementAzure API Center Introduces a Data Plane MCP Server for Enterprise-Wide API and AI Asset Discovery
As organizations scale their adoption of MCP-based tooling and AI agents, one challenge keeps surfacing: developers spend too much time figuring out what APIs, tools, and AI assets exist β and then manually wiring up connections to each one. Today, we're excited to announce general availability of a new capability that changes that. What's new Azure API Center now provides a data plane MCP server β a unified enterprise discovery endpoint that gives agents and developer tools a single connection point to your organization's full catalog of registered MCP servers, tools, APIs, and AI assets. Instead of hunting across systems or hand-configuring integrations one by one, developers and agents can now connect once and immediately access everything that's been registered in your API Center. Why this matters The MCP ecosystem is growing fast. So is the number of enterprise APIs and AI assets that teams need to manage and consume. Without a central discovery mechanism, that growth creates friction β more manual configuration, more drift between what's available and what's actually reachable, and more integration complexity for every new agentic application. The Azure API Center data plane MCP server addresses this directly. With it, teams can: Give agents centralized access to enterprise APIs and AI assets without custom routing logic Eliminate manual configuration of connections to individual MCP servers Automatically surface newly registered MCP servers and tools without reconfiguration Simplify discovery and consumption across a rapidly growing enterprise catalog Built for how organizations actually operate Agentic applications don't just need APIs β they need to find the right APIs, trust that the catalog is current, and connect reliably at scale. By acting as a unified discovery endpoint, Azure API Center helps teams operationalize AI ecosystems with stronger discoverability, governance, and developer productivity, while meaningfully reducing integration complexity. This is especially valuable as enterprises move from experimenting with AI agents to deploying them in production workflows, where manual integration approaches don't scale. How to enable the data plane MCP server Turning on the MCP server takes just a few clicks in the Azure portal. Navigate to your API Center instance and open Data API settings under the Consumption section in the left-hand menu. From there, under MCP endpoint, toggle Enable API Center MCP endpoint to on. Once enabled, your MCP endpoint URL (in the form https://<your-instance>.data.<region>.azure-apicenter.ms/mcp) will appear and can be copied directly for use in agent configurations or developer tools. Note: When enabled, the MCP endpoint is also surfaced on the developer portal homepage, so developers can connect via CLI without needing to look up the URL separately. You can also enable the Plugin marketplace endpoint from the same settings page to let developers browse and install approved plugins and skills from your organization's marketplace. The Visibility section lets you control which APIs are exposed through the data plane β use Add condition to filter the catalog based on your governance requirements. Get started Learn more about Azure API Center and how organizations are building unified catalogs for APIs, MCP tools, agents, and AI assets.Find what you need, faster: Azure API Center now supports custom metadata filtering
Enterprise API and AI catalogs have expanded dramatically. Where teams once managed dozens of APIs, they now govern hundreds β spanning business units, environments, compliance domains, and an ever-growing roster of AI assets. The catalog itself has become a discovery challenge. What's new Developers can now filter catalog assets using organization-defined metadata attributes. These aren't generic tags β they're the classifications your organization already uses: environments, business units, domains, compliance tiers, ownership groups, and more. Custom metadata filtering works across all major asset types in Azure API Center: APIs Skills Agents MCP tools Why it matters Discovery friction is a hidden tax on developer productivity. When a developer needs to find the right API for a project, every minute spent navigating inconsistent lists or applying manual filters is a minute not spent building. At scale, this compounds quickly. Custom metadata filtering addresses this directly by aligning the catalog's search experience with how your organization already thinks about its assets: Surface the right assets faster β filter by internal classifications and governance models instead of browsing overwhelming lists Improve discoverability at scale β no need to retag or reorganize existing assets to make them findable Align with your organizational taxonomy β filter by domain, environment, business unit, compliance requirement, or any custom attribute your teams already use Built for governed, AI-ready teams This update reinforces Azure API Center's role as the foundation for scalable, AI-ready discovery experiences β where governance and developer velocity move together, not against each other. By making enterprise catalogs easier to navigate, Azure API Center helps developers spend less time searching and more time building with governed APIs and AI assets. Get started Learn more about Azure API Center custom metadata filtering and how organizations are building scalable, AI-ready discovery experiences.GA: Azure API Center Now Supports Plugin Registration
As organizations scale their AI and integration ecosystems, one challenge keeps surfacing: developers don't have a reliable, governed way to discover and reuse the plugins their teams have already built. Plugins end up siloed in individual repos, shared over Slack, or duplicated across teams β slowing down development and creating governance blind spots. What's new With this update, developers can register plugins directly into Azure API Center's enterprise catalog. Once registered, plugins are discoverable, governable, and consumable alongside the rest of an organization's API and AI portfolio β no more hunting across repositories or relying on word-of-mouth to find what's already been built. Why it matters Plugins are increasingly central to how AI-powered applications are built. Agents depend on them. Integrations are built on top of them. But without a governed home, even well-built plugins go undiscovered and get rebuilt from scratch. Plugin registration in Azure API Center helps organizations: Centralize plugin discovery within a governed catalog, so developers always know where to look Surface vetted plugins that teams can confidently find and reuse β reducing duplication and accelerating development Align plugins with source-controlled workflows, keeping development practices consistent across the catalog Reduce friction between building a plugin and enabling it for real-world integration One catalog for your entire AI ecosystem This update reflects a broader vision for Azure API Center: a single, unified catalog for everything an organization builds and consumes β APIs, plugins, agents, and AI assets. By bringing plugins into this experience, teams can operationalize reusable integration and AI capabilities at scale, with the governance and discoverability that enterprise development requires. Whether your teams are building copilot extensions, orchestration layers, or custom integrations, Azure API Center gives them a governed foundation to build on β and a shared place to discover what's already there. Learn more about Azure API Center and how organizations are building centralized catalogs for APIs, plugins, agents, and AI assets.Azure API Center now supports agent registration, agent assessment, and Git-based synchronization
What's new Three capabilities are now generally available: Capability What it does Agent registration Register agents directly into the enterprise catalog for cross-team discovery and reuse. Agent assessment LLM-as-a-Judge framework scores agents across 6 criteria before catalog registration. Git synchronization Connect a repo and keep agent definitions automatically in sync with source control. Agent assessment β six weighted criteria, automatically enforced When assessment is enabled, every agent is scored on creation or update. Up to 8 criteria are supported; weights are fully configurable by platform teams. Criterion Weight What it evaluates capability-transparency 0.15 Documents tools, delegated capabilities, external systems, access levels, and capability boundaries. composition-resource-discipline 0.15 Named skill/sub-agent references, invoke guidance, no inline duplication, resource/token constraints. operational-protocol-quality 0.25 Structured workflow with named steps, decision points, failure modes, recovery paths, and pre-flight checks. output-contract 0.10 Specifies output format, mandatory sections, evidence requirements, confidence semantics, and dead-end handling. purpose-scope-clarity 0.15 Clear role identity, type (specialist/orchestrator), activation triggers, anti-triggers, and refusal behavior. safety-consent-architecture 0.20 Classifies risk, distinguishes idempotent vs approval-required actions, enumerates NEVER/ALWAYS rules, documents failure-mode safety. Git-based synchronization β connect once, stay in sync automatically Integrating a Git repository creates an environment in API Center representing the repo as an asset source. API Center polls for changes and reflects them in Inventory > Assets β linked assets display a provenance icon. Agent definitions live in source control and evolve continuously β yet keeping a catalog manually in sync with a codebase is slow, error-prone work that no platform team should have to do. Git-based synchronization connects Azure API Center directly to your repository, polling for changes and reflecting them in the inventory automatically so the catalog always represents the current state of your agents. Linked assets carry a provenance icon that traces them back to their source repository, giving developers immediate visibility into where an agent comes from and whether it is actively maintained. Because assessment gates run before any version is promoted from the repo into the catalog, only agents that meet your organization's quality criteria ever reach developers β enforcing governance at the point of commit, not as an afterthought. A single integration supports multiple asset types through configurable file patterns, so teams can sync agents, skills, and APIs from one repository with per-type control and no duplication. A2A agent sync from Azure API Management β publish once, discover everywhere Azure API Management β continuous sync β Azure API Center One-way Β· updates within minutes Β· includes API definitions, environments & deployments As teams publish more A2A agents through Azure API Management, manually registering each one into a discovery catalog creates friction that slows developer productivity and risks catalog staleness. Azure API Center now automatically synchronizes A2A agents β alongside APIs and MCP servers β published in an API Management instance, so every agent that reaches runtime is immediately visible in the centralized catalog without any additional registration step. The sync is continuous and one-way: when agents are created, updated, versioned, or deleted in API Management, those changes propagate to API Center within minutes, keeping the inventory accurate at all times. Each synchronized agent gets an associated environment and deployment record, giving developers the runtime context they need to discover and integrate the right agent with confidence. This closes the loop between runtime publishing and centralized governance, helping organizations operationalize agent ecosystems at scale without burdening platform teams with manual catalog maintenance. Why it matters By bringing agents into Azure API Center alongside APIs, plugins, skills, and MCP tools, organizations gain a single pane of glass for everything their AI applications depend on. Teams reduce duplication, improve reuse, and accelerate development β while maintaining the governance standards enterprise deployments require. Get started Azure API Center overview Set up Git-based synchronization Sync A2A agents from API Management