Hosted MCP Servers in Connector Namespace (Preview)
Imagine you've built an agent and you want to give it access to tools via MCP servers. Local servers won't work because your agent can't connect to them in production. Wouldn't it be great if you could quickly stand up secure, enterprise-ready remote MCP servers that your agent can use? This is what Connector Namespace enables. Among other capabilities, the namespace provides a feature called hosted MCP servers that lets you deploy remote MCP servers in minutes. Pick a server from the catalog, deploy it and your agents can discover and call its tools immediately, with infrastructure, deployment, scaling, observability, authentication, and more handled by the platform. Why hosted MCP? Self-hosting MCP servers comes with real operational cost: infrastructure, authentication, monitoring, scaling, availability, and debugging are all on you. For servers that expose standard capabilities like database access or browser automation, that's undifferentiated work that slows you down. Hosted MCP servers shift that burden to the platform, offering a fully managed experience so you can just pick a server and let the platform handle everything else: Hosted MCP server Self-hosted MCP server Setup Deploy from catalog in minutes Build/find server, deploy to your own infra, wire up networking Scaling Platform-managed, scales automatically You configure and manage scaling (VMs, containers, load balancers) Auth Inbound and outbound auth handled by the platform You configure OAuth, managed identity, or OBO end-to-end Observability One-click App Insights integration You set up logging, metrics, and alerting yourself Cold starts Platform manages server lifecycle You manage warm-up, health checks, and process restarts Availability Platform-managed uptime, health monitoring, and automatic recovery You own high availability, e.g. failover and redundancy How it works When you deploy a hosted MCP server, the namespace: Pulls the pre-built server image from the catalog. Provisions the runtime environment with your configuration. Exposes a secure MCP endpoint that agents and MCP clients can connect to. Handles scaling, health monitoring, and authentication. Public preview feature highlight Supported servers During public preview, a curated set of hosted MCP servers is available. The catalog expands over time based on demand. Server What it does Playwright Browser automation tools for web navigation, screenshots, and interaction Azure SQL Exposes SQL operations as MCP tools through Data API builder, enabling AI agents to interact with SQL databases through a controlled, secure contract with entity abstraction, RBAC, and caching. If there's a server you'd like to see in the catalog, file an issue at aka.ms/hosted-mcp-github. Support for publishing custom-built MCP servers to the catalog is planned for the future. Authentication Hosted MCP servers involve two authentication boundaries: Inbound (client → server): OAuth-based authentication with Microsoft Entra ID. Connections from GitHub Copilot in VS Code work out of the box. Outbound (server → downstream service) The server authenticates to the downstream service using either managed identity or on-behalf-of (OBO) flow. You choose the approach during deployment, and the platform handles the rest, including credential management and token exchange. Observability Hosted MCP servers integrate with Azure Application Insights], so you can monitor server health without setting up your own logging infrastructure. After deployment, you can enable monitoring by providing your Application Insights connection string. Once configured, logs and metrics from the server flow directly into your Application Insights resource, where you can search, filter, and analyze them. Get started Quickstart: Create a hosted MCP server in Connector Namespace Hosted MCP overview: Hosted MCP servers in Connector Namespace Connector Namespace overview: What is Connector Namespace? Try it out and let us know what you think! File feedback and feature requests at aka.ms/hosted-mcp-github. What's next Hosted MCP servers are in public preview and the team is actively working to improve the experience. We're looking for your feedback to help shape what comes next. Some areas we're prioritizing: Expanding the server catalog: adding more servers based on demand and community requests Region availability: expanding regional coverage beyond the current preview regions VNet support: deploying Hosted MCP servers inside virtual networks with private endpoints Custom server images: support for bringing your own MCP server images to the catalog Tool-level access control: fine-grained permissions and throttling at the individual tool levelWrite Logic Apps in C#: introducing the Logic Apps Standard SDK
The workflow you always wished you could write in code If you build on Logic Apps Standard, you already know the deal: the runtime is excellent at the unglamorous parts of integration - connecting to systems, retrying, scaling, keeping run history you can actually debug. What you sometimes wanted was a different front door. You're a .NET developer. You live in C#, source control, and pull requests. And for a long time, authoring a workflow meant leaving all of that behind for a visual designer and a JSON file. That's the gap the new Logic Apps Standard SDK closes. It lets you define Logic Apps Standard workflows in code - strongly typed, IntelliSense-guided C# - without giving up a single thing the runtime already does for you. What is the Logic Apps Standard SDK? The Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk) is a NuGet package that gives you a fluent, code-first way to build workflow definitions in C#. Instead of dragging actions onto a canvas, you compose a workflow with method chaining: a trigger, then the actions that follow it, all the way to a response. Worth saying clearly, because people ask: this is a new way to define workflows - not a new runtime. The workflows you write with the SDK compile down to the same definitions and run on the same Logic Apps Standard runtime you use today. Same connectors. Same hosting. Same rich run history and monitoring. You're changing the authoring experience, not the engine underneath it. Why this matters for developers When your workflow lives in C#, it behaves like the rest of your code. A few things fall out of that almost for free: Type safety and IntelliSense - connector operations, triggers, and outputs are discoverable as you type, and the compiler catches mistakes before you run anything. Real source control and reviews - workflows diff like code, get reviewed in pull requests, and version alongside the services they orchestrate. Familiar tooling - refactor, debug with F5, and lean on the .NET ecosystem you already know. Extensibility on your terms — Compose your workflow declaratively with the fluent builder, then drop into plain imperative C# wherever a step needs logic that might be too complex to implement declaratively - loops, branching, a call into your own library, all encapsulated in a step of your workflow - without leaving the file or the language. And it isn't limited to one style of work. The SDK covers both enterprise integration workflows - the connect-systems-and-move-data scenarios Logic Apps is known for - and agentic workflows, where a conversational or autonomous AI agent drives the steps. Both are first-class in the same SDK, built from the same building blocks. There's one more angle worth calling out, because it's becoming hard to ignore: coding agents are simply better at writing imperative code than declarative JSON. And the reason is the same set of guardrails that helps you. Strong typing and a compilation step mean the code an agent produces is syntactically correct out of the gate — the type system and the compiler do the checking, so you don't have to. Layer unit tests on top and you've covered north of 90% of what matters; what's left is integration testing. Getting an LLM to the same level of accuracy against declarative JSON means building dedicated tooling to stand in for everything the compiler gives you for free. With code-first workflows, those guardrails are just there — which makes this a natural fit for an agent-assisted way of building. Getting started Everything here lives in the Logic Apps extension for VS Code. You'll want the Logic Apps Standard VS Code extension version 5.961.10 or later, which includes all the components you need to create code first workflows. Beyond that, the prerequisites are the ones you'd expect - VS Code with the Logic Apps extension, an Azure subscription you can create resources in, and a working comfort with C# and .NET. From a clean start, you're a handful of steps from a running workflow: Create the workspace — launch the Logic Apps extension and choose Create new Logic Apps workspace. Pick a folder, name the workspace and project, and when prompted for the workflow type, choose Logic Apps codeful - that's the code-first option that uses the SDK. Pick a workflow kind - name your first workflow and choose how it runs: Stateful, Autonomous agents (Preview), or Conversational agents (Preview). The agent options are where the agentic scenarios live. Enable connectors - when prompted, select Use connectors from Azure, choose your subscription and resource group, and pick Connection Keys for authentication. Managed identity is still in development, so connection keys are the way in for now. Find your way around - the project opens with Program.cs, which builds and starts the host, plus a workflow file (like workflow1.cs) where your trigger and actions are defined. The SDK compiles those definitions and runs them on the Logic Apps runtime. Run it - press F5 (or right-click Program.cs and pick Overview). The runtime starts locally and an overview page opens where you can fire triggers, watch run history, and inspect inputs and outputs. That last part is worth dwelling on: run history for SDK workflows uses the same rich visual view as designer-built ones. You author in code, but you monitor and troubleshoot exactly as you always have. A look at the capabilities Connectors and triggers Every workflow starts with a trigger and runs a series of actions. The SDK exposes both through two entry points - WorkflowTriggers and WorkflowActions - each split into BuiltIn and Managed. Built-in triggers and actions run directly in the runtime: HTTP request, recurrence, and the conversational agent trigger; actions like Compose, HTTP, Response, and custom code. Managed connectors give you the full Logic Apps connector catalog - Service Bus, SharePoint, SQL, and hundreds more - typed and ready to call. The managed surface is generated from the same connector definitions the designer uses, so the operations you know are right there: // Built-in trigger var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // Managed connector action — full catalog, strongly typed var getItems = WorkflowActions.Managed .Sharepointonline("sharepoint") .GetItems( dataset: () => "https://contoso.sharepoint.com", table: () => "orders-list-id") .WithName("GetOrders"); The fluent API streamlines the definition This is where it comes together. You compose a workflow by chaining operations with .Then(...). The shape of your code mirrors the shape of your workflow - read it top to bottom and you read the execution path. trigger .Then(validateOrder) .Then(getOrders) .Then(sendResponse); Control flow is part of the same fluent model. Built-in structures like Condition (if/else) and ForEach - along with Switch, Until, Scope, and Terminate - are just actions you chain in, each taking a small factory for the branch or loop body: var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => order.Total > 1000, trueBranch: () => requireApproval, falseBranch: () => autoApprove ).WithName("CheckOrderValue"); And ForEach takes the collection to iterate and a factory that builds the body for each item: var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => order.LineItems, actions: (item) => new WorkflowBuiltInActions() .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); Need parallel branches that fan back in? The same Then pattern handles branching and join - no JSON wiring, no run-after blocks to hand-edit. Extending workflows with custom code Some logic doesn't belong in a connector or an expression - it's just code. The CustomCode action lets you drop a real C# method into the middle of a workflow. It receives a WorkflowContext, so you can read the trigger payload or any earlier action's results and return a strongly typed value the next step can use: var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var trigger = await context.GetTriggerResults(); var order = await context.GetActionResults("GetOrders"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); That's the escape hatch that keeps you in flow: when a step needs custom transformation, validation, or a call into your own libraries, you write a method instead of bending an expression to do something it was never meant to. Handling failures: try/catch with run-after Real workflows have to deal with things going wrong, and the SDK gives you the same try/catch shape Logic Apps has always had - expressed in code. The .Then(...) overload takes a FlowStatus[] run-after condition, so a handler runs only when the step before it ends in a status you name. Wrap the risky work in a Scope (your try), then chain a handler that runs after it Failed or TimedOut (your catch): var tryProcess = WorkflowActions.BuiltIn.Control.Scope(() => callPaymentApi.Then(saveOrder) ).WithName("ProcessPayment"); var handleFailure = WorkflowActions.BuiltIn .Compose(inputs: () => "Payment failed — compensating") .WithName("HandleFailure"); trigger .Then(tryProcess) .Then(handleFailure, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); The status set is the whole vocabulary: Succeeded, Failed, Skipped, and TimedOut. Combine them however a step needs - a cleanup action that should run no matter what can list every status; a finally is just the union. The same idea scales to fan-in. When several parallel branches converge, the per-predecessor RunAfter overload lets the join wait on each branch independently - so you can require some to succeed and tolerate others failing: leftChain .Join(rightChain) .Then(merge, runAfter: new[] { new RunAfter(leftChain, FlowStatus.Succeeded), new RunAfter(rightChain, FlowStatus.Succeeded), }); Putting it together Here's a small but complete shape - an HTTP-triggered order workflow that validates input, branches on order value, loops over line items, runs custom code, and replies. The core steps live in a Scope so a single failure handler can catch anything that goes wrong, and a clean reply only runs when the work succeeds. Notice it's all one readable chain: namespace LogicApps { using Microsoft.Azure.Workflows.Sdk; using Microsoft.Azure.Workflows.Sdk.Connectors.Msnweather; using System.Net; public class OrderWorkflow : IWorkflowProvider { /// <summary> /// Gets the HTTP request/response workflow definition. /// </summary> public FlowDefinition[] GetWorkflows() { // --- Trigger ---------------------------------------------------- var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // --- Managed connector action (full catalog, strongly typed) ---- // Reused verbatim from the confirmed stateful1.cs pattern. var getWeather = WorkflowActions.Managed.Msnweather("msnweather").CurrentWeather( location: () => "98058", units: () => unitsInput.Imperial).WithName("GetWeather"); // --- Custom code: real C# in the middle of the workflow --------- var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var triggerResults = await context.GetTriggerResults(); var weather = await context.GetActionResults("GetWeather"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); // --- ForEach over a collection (control flow via .Control) ------- var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => trigger.TriggerOutput.Body["lineItems"], actions: (item) => WorkflowActions.BuiltIn .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); // --- Condition (if/else) (control flow via .Control) ------------ var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => true, trueBranch: () => processLines, falseBranch: () => WorkflowActions.BuiltIn .Compose(inputs: () => "Auto-approved").WithName("AutoApprove") ).WithName("CheckOrderValue"); // --- Scope groups the core steps so one handler catches failures - var processOrder = WorkflowActions.BuiltIn.Control.Scope(() => checkTotal .Then(getWeather) .Then(enrich) ).WithName("ProcessOrder"); // --- Responses -------------------------------------------------- var ok = WorkflowActions.BuiltIn.Response( responseBody: () => "Order processed").WithName("Reply"); var failed = WorkflowActions.BuiltIn.Response( statusCode: () => HttpStatusCode.InternalServerError, responseBody: () => "Order failed").WithName("ReplyFailed"); // --- Assemble --------------------------------------------------- // Happy path runs after the Scope Succeeded; the handler runs after // Failed or TimedOut. trigger .Then(processOrder) .Then(ok, runAfter: new[] { FlowStatus.Succeeded }) .Then(failed, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); return new[] { WorkflowFactory.CreateStatefulWorkflow("OrderWorkflow", trigger) }; } } } That last stretch is the best-practice shape in miniature: the happy-path Reply runs only after the Scope Succeeded, while a separate handler catches Failed or TimedOut and returns a 500 - no exception plumbing, just run-after conditions. You implement IWorkflowProvider, hand your trigger graph to WorkflowFactory as a stateful, stateless, or agent workflow, and the host registers it. Run it with F5 and the Logic Apps runtime starts locally - same as any Standard project. Before you build: preview realities I'd rather you go in clear-eyed. While the SDK is in public preview, keep these in mind: Service Provider connectors aren't supported yet - that connector type is coming in a future release. Dynamic schemas aren't supported - support is planned. Custom code supports callback methods only - inline lambdas aren't available in this version. Define and name actions before referencing them - name an action before using it as a dependency elsewhere. Managed identity authentication is in development - use connection keys for connectors in the meantime. Try it, and tell us what you think If you've ever wanted your workflows to live where the rest of your code lives - in C#, in source control, in your pull requests - this is for you. Install the Logic Apps extension for VS Code, create a Logic Apps codeful project, and build your first workflow in code. This is a preview, which means your feedback genuinely shapes where it goes - which capabilities come next, where the rough edges are. Bring issues, feature requests and feedback to our GitHub page. I read it. Let's make code-first workflows something you actually want to use.Azure Connector Namespaces: managed integration for any Azure compute
The integration tax nobody budgets for It is always a simple task on paper: connect apps to the systems the business actually runs on — SharePoint, Salesforce, SAP, Outlook — and get back to building features. What gets in the way is rarely the business logic. It's the plumbing. You write a custom API client for each service. You wire up OAuth flows and then babysit token refresh. You add retry policies, handle throttling, page through results, and stand up webhook subscriptions you now have to keep alive. None of that is the feature. All of it is on you. Historically, if you wanted that work done for you, the answer was a workflow engine. That's great when you want a workflow — but a lot of apps just want to call an action or react to an event from code they already have, running on the compute they already use. That's the gap Azure Connector Namespace fills. What is Azure Connector Namespace? Azure Connector Namespace is a fully managed integration service that hosts a catalog of prebuilt, reusable connectors and MCP servers that your apps consume through a consistent programming model. Instead of writing and operating a client for each system, you create a connection once and call typed operations from your code. The namespace handles authentication, credential rotation, polling, webhook delivery, retries, throttling, and error handling on your behalf. Worth saying clearly, because people ask: a connector namespace is independent of Azure Logic Apps. It doesn't require, use, or change anything in Logic Apps, and the Logic Apps connectors gallery keeps working separately for workflows. Connector Namespace is the integration path for compute that doesn't run on a workflow engine — your Functions, Container Apps, App Service, and self-hosted services. Each connector exposes three kinds of surface through one shared connection model: Triggers — event subscriptions your app registers (a new email arrives, a record updates, a file lands in a folder). Actions — operations your app calls (send a message, read a row, upload a file). AI agent tools — the same operations, exposed to agents and Copilot through MCP servers. You call all of it from strongly typed SDKs for C# (Azure.Connectors.Sdk), Node.js (@azure/connectors), and Python (azure-connectors) — or over plain HTTP if a typed SDK isn't a fit. The building blocks Five concepts and you have the whole model: Concept What it is Connector namespace The Azure resource that hosts the connector runtime — loads and runs operations, maintains connection state and credentials, polls source systems, dispatches webhook events, and applies retry and diagnostic policies. Create it from the Azure portal, ARM/Bicep, or the CLI. Connector A prebuilt component for one service (SharePoint, Salesforce, SAP, Outlook). It abstracts the underlying API, auth protocol, pagination, and retry behavior so your code stays on business logic. Connection An authenticated, configured binding to an account or tenant. Connections are reusable — multiple apps and connectors can share one. Auth types: OAuth, API key, and Basic. MCP server A first-class resource that exposes tools to AI agents over the Model Context Protocol. Comes in managed and hosted flavors (more below). Connector SDKs Strongly typed clients for C#, Node.js, and Python that share the same catalog, connection model, telemetry, and retry semantics. Or call connectors over HTTP. What you can actually do with it The point of all this is the scenarios it unlocks. A few that show the range: Scenario What it looks like Process documents and content An Azure Function uses SharePoint connector operations to detect new or updated files, processes them, and writes results back to SharePoint. Monitor events from external services An Azure Container App uses a Salesforce trigger to receive events about new leads as they're created. Automate productivity A Node.js app uses Outlook operations to read and send email — reusing a connection another app already owns. Ground AI and agentic workloads A Python service calls connector actions to enrich model output with data from business systems. Reuse existing app code ASP.NET, Node.js, and Python services use managed integrations with no workflow engine in the call path. Publish connectors to agents Turn any connector into an MCP server in one step so Copilot and other agents can call it as a tool. Connections: authenticate once, reuse everywhere Connections are where the Logic Apps connector ecosystem pays off. You get the same broad catalog of first-party Azure services and popular SaaS apps — built on years of connector investment — without bringing a workflow engine along for the ride. You create a connection to a service, authenticate it once, and then any number of apps and connectors reuse it. Creating one is deliberately simple, which is the point: In the Connector Namespaces portal (connectors.azure.com), open your namespace and select Connections > Create connection. Find and select the connector — say, Office 365 Outlook. Give the connection a clear, specific name so it's easy to pick later. Sign in to authorize, and complete any extra steps the service requires. Confirm the connection shows as healthy on the Overview page — it's now ready for your apps to use. Supported authentication types today are OAuth, API key, and Basic. And because the namespace stores and rotates the credentials, your app never touches a raw secret. Triggers: deliver events to the compute you already run A trigger is an event subscription your app registers on a connector — new email, updated record, new file. When the source system raises that event, the namespace delivers the payload to your compute. And it does the hard part for you: it manages polling schedules and webhook registration based on what the underlying service supports, so you don't stand up or maintain subscription infrastructure. Your app can receive those events running on: Azure Container Apps Sandboxes Azure Functions Direct HTTP — App Services or self-hosted ASP.NET, Node.js, or Python on AKS or VMs, through the same connector namespace. Two details that matter in practice: a trigger is defined independently of any specific app, and multiple apps can subscribe to the same trigger event over the same connection. Actions, for contrast, run synchronously when your app calls them; trigger delivery uses webhooks or pull-based subscriptions depending on the connector and source service. You can learn more about how to use the Connectors SDK to inject connectors on Azure Functions here. MCP servers: turn connectors into agent tools This is the part I'm most excited about. An MCP server in your namespace exposes tools that AI agents — Copilot, custom agents, any MCP-aware client — can discover and call, using the same connection model as everything else. That's how you put your line-of-business systems directly in front of an agent without writing tool wrappers or standing up hosting. There are two ways to get one. Managed MCP servers Take any connector in your namespace and publish it as an MCP server in a single step. The namespace builds and configures the server — tool definitions, lifecycle, runtime — and the only thing you do is authenticate the underlying connection. If you can create a connection, you can give an agent a tool. Hosted MCP servers Sometimes you want a ready-made server rather than one projected from a connector. Hosted MCP servers are pre-built images from a curated catalog that the namespace runs in dedicated compute it provisions for you. You own the configuration; the platform handles hosting, scaling, networking, lifecycle, dependencies, health monitoring, and credentials. When you deploy one, the namespace pulls the image, provisions the runtime with your config, and exposes a secure MCP endpoint agents can connect to. The curated catalog during preview includes: Playwright — browser automation tools for navigation, screenshots, and page interaction. Azure SQL — SQL operations exposed as MCP tools through Data API builder, with entity abstraction, RBAC, and caching so agents work through a controlled, secure contract. It's a deliberately curated set today, and it expands over time based on demand. You can learn more about Hosted MCP Servers here. How agents authenticate Hosted MCP servers have two auth boundaries: Inbound (client to server) — OAuth with Microsoft Entra ID. Connections from GitHub Copilot in VS Code work out of the box; other MCP clients need a little extra config. Outbound (server to downstream system) — either a managed identity assigned to the namespace, or on-behalf-of (OBO) using the calling user's identity for delegated access. How it fits together End to end, the flow for connectors is short: Create a connector namespace resource in your subscription. Create one or more connections to the services you want — say, an OAuth connection to Microsoft 365. Your app — in Functions, Container Apps, App Service, or self-hosted compute — references the namespace and connection through a Connector SDK, then subscribes to triggers or calls actions. The namespace handles authentication, request signing, polling, webhook subscription, and retries. Your app gets back typed responses and event payloads. For MCP servers, it's the same shape: create the namespace, add a managed or hosted server from the catalog, authenticate the underlying connection, and agents can find the server, read its tool catalog, and invoke tools. Where you can run it Azure compute — App Service, Container Apps, and Functions can all consume connector operations. Self-hosted — any self-hosted service works too: ASP.NET, Node.js, or Python on AKS or Azure VMs. Agents, directly — Copilot extensions and MCP-aware clients call tools on MCP servers in your namespace without going through a separate compute layer; the namespace provides the compute that runs the servers. Security and governance, by default Credentials stay with the namespace — it stores, manages, and rotates them; your app never handles raw secrets. Network isolation — restrict access with virtual network integration and private endpoints. RBAC — control who can create connections, register triggers, and invoke actions. Observability — diagnostic logs and correlation IDs flow to Azure Monitor for end-to-end tracing across the namespace and your compute. Before you build: preview realities I'd rather you go in clear-eyed. While Connector Namespace is in preview, keep these in mind: Consideration What to expect No SLA Not recommended for production workloads during preview. Region availability Limited regions today; the list expands over time. Connector coverage High-usage and standard connectors first; enterprise connectors like SAP, IBM MQ, and Oracle Database follow in later waves. Identity API key and OAuth connections now; managed identity for connections comes later (and arrives earlier for select MCP servers). Versioning SDK and namespace runtime versions are paired during preview — expect breaking changes between milestones. Pricing The pricing model isn't finalized; the metering shape may change before GA. Try it, and tell us your feedback If you've ever shipped an integration and then spent the next quarter maintaining its plumbing, this is for you. The preview is open: create a namespace from the Azure portal, wire up a connection at connectors.azure.com, and call your first action or publish your first MCP server. It is easy to start here: Learn more: What is Azure Connector Namespace? Quickstart: Create and manage connector namespaces Create reusable connections in connector namespaces Hosted MCP servers in Azure Connector Namespace Related Blog Posts: Azure Functions - Connectors SDK Hosted MCP Server announcement Samples repositories: Using connectors SDK with Azure Functions This is a preview, which means your feedback genuinely shapes where it goes — which connectors come next, which MCP servers land in the catalog, where the rough edges are. Bring issues, feature requests and feedback to our GitHub page. I read it. Let's build the integration layer you actually want to use.
More 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 ManagementOracle Eloqua integration for Teams webinars
Would like to see Microsoft add or support an integration with Oracle Eloqua for Teams Webinars, as our Marketing team needs this integration in order to fully migrate to Microsoft Teams for our customer facing events. They continue to use an antiquated (competitor) platform because it does have the Eloqua integration.Run Javascript code on Agent Loop
We have recently introduced support for Code interpreters inside of Azure Logic Apps Agent Loop, extending the support we had for Python. When partnered with a LLM, this allow builders to express their goals or intents via natural language and obtain executable results. These capabilities become powerful in the areas of data analysis, visualizations, validations and transformations. Our first language supported for code interpreter is JavaScript, with other languages following later. Historically, customers have had concerns about an LLM performing data analysis, calculations and transformations due to context window exhaustion which can lead to hallucinations. Code interpreters help in this regard as they can perform this analysis without filling up context windows and providing more reliable results. You can see the code interpreter with JavaScript in action in this video from Kent Weare. After watching the video, you can deep dive in the details. How it works When Agent Loop evaluates code generated by an AI agent (for example, through a code interpreter), we run it inside a V8 isolate using the isolated‑vm library. V8 is the JavaScript engine that powers Node.js and Chrome—it’s what actually executes JavaScript code. An isolate is a lightweight, independent environment within V8, with its own memory and execution context. Running code inside an isolate gives us strong separation from the host runtime. Each execution has its own memory (“heap”) and cannot directly access the host’s memory, file system, or network. This helps ensure that agent-generated code stays contained and doesn’t interfere with the rest of the system. This approach is not intended to be a full security sandbox, and we don’t treat it as safe for fully untrusted code. However, it provides meaningful defense-in-depth: Memory usage is limited per isolate, preventing a single execution from consuming all available resources Execution can be bounded with timeouts, allowing us to terminate long-running or infinite loops Failures are isolated, so crashes in agent-generated code won’t bring down the runtime process In practice, this is about reducing blast radius. By isolating execution and enforcing limits, we make sure that code—regardless of whether it’s generated by a user or an AI agent—cannot disrupt the engine that runs it. Use case: Expense Validations To help illustrate, this capability, let’s take an accounts payable example built in Logic Apps Standard. Zava uses a 3 rd party expense application to capture employee expenses. The 3rd party expense application will export transactions in CSV format. Zava has some very specific business validations that need to execute before the expenses can be processed by the ERP. To solve this problem, we will build an agentic business process in Logic Apps that includes our new JavaScript code interpreter. Our code interpreter will be able to ingest and parse our CSV file and then apply our business validations for us. The outcome is a report that identifies both valid and invalid transactions. Prior to uploading to the ERP (Dataverse), we will route our request to a human in the loop process for their oversight. This allows for additional control as unwinding in an ERP is always a tedious task. Below, is a picture of our solution. Within it we can see both deterministic steps before and after our Agent action. Within our agent action, we have tools that will help our agent address our company objectives. These tools include calling a batch API to upload valid expense records to Dataverse. Another tool that will take care of uploading invalid records to a different table, our human in the loop action to seek approval from our human stakeholder and a tool that will help us obtain business knowledge from SharePoint. You might be asking, ok where does the code interpreter come in? Within our Agent action, we will discover a toggle that allows you to enable it. The code interpreter gets invoked based upon instruction in the model. Here is a subset of the prompt from this workflow that describes how to invoke the code interpreter. For example: ### Step 2 -- Parse and Validate The expense CSV data is available from the Get_file_content action. Use code interpreter to parse ALL rows from the CSV. For each row, normalize: Category: title case - Amount: decimal number - SubmittedDate: ISO 8601 format (e.g. "2026-01-05T00:00:00Z") - ReceiptAttached: convert "Yes"/"No" to true/false Then apply the business rules from Step 1 to classify every record as VALID or INVALID. You won’t see the code interpreter modelled as a tool within our agent action, but we see the execution outcome within our run history. In the following screenshot we can see this illustrated. Within our agent action, we can see that we are on our 4 th turn and we have executed the code interpreter action. In the code window, we can see the code that was generated for our us. This is the result of the LLM working together with the code interpreter to generate and execute this code. Note: In this scenario, we are dynamically generating this code at runtime. This allows for ultimate flexibility if we have different source inputs and we are relying upon the LLM and code interpreter to adapt to these fluid inputs. If we were interested in a more deterministic approach we can also pass pre-written code into this action where it can also execute. This will result in less flexibility, but more deterministic behavior. Running JavaScript code in Logic Apps Consumption Agent Loop Logic Apps Consumption has a slightly different architecture to Logic Apps Standard. In Logic Apps Standard, we offer dedicated compute and storage for customers which provides workload isolation across customers. When it comes to Logic Apps Consumption, we provide a multi-tenant offering allowing customers to take advantage of a lower price point due to shared resource utilization. In order to allow customer isolation, customers need to have an integration account attached to their consumption workflow. This will allow the code interpreter to run in isolated compute thus avoiding any potential disruptions to other customers. You can provision an Integration Account by searching for Integration Accounts at the top of the Azure portal. You can select any of the SKUs available, including the Free SKU for non-production/non-SLA scenarios. With an Integration Account created, we can associate this Integration Account with our consumption logic app by clicking on Settings – Integration Account.
