Model Context Protocol on Azure (Insights from Build 2025)

For discussion at work, I did some deep-research of MCP related announcements at Microsoft Build last week. If you are developing on Azure, here is everything what you need to know.

Microsoft Build 2025 was centered on enabling an “open agentic web” – a future where AI agents can seamlessly interact with data and services across platforms. A cornerstone of this vision is the Model Context Protocol (MCP), an open standard that bridges AI models (agents) with external tools and data via a standardized API. Microsoft announced broad first-party support for MCP across its ecosystem, including GitHub, Microsoft 365 Copilot Studio, Dynamics 365, Azure AI Foundry, Semantic Kernel, and even Windows . This means Azure and Microsoft’s developer platforms are being updated to natively recognize MCP-enabled tools and data sources, making it easier for your AI applications to call into external APIs or knowledge bases in a consistent way. Microsoft also joined the MCP steering committee and contributed an updated authorization spec and registry design – enabling agents to use existing Entra ID (Azure AD) sign-ins to securely access MCP tools, and defining a central MCP server registry to catalog available. All of these efforts underscore that Microsoft is embracing MCP as the interoperability layer for AI agents.

In Copilot Studio MCP support has become generally available. For example, Microsoft 365 Copilot Studio now uses MCP to give enterprise agents governed, consistent access to external data and models. Microsoft even announced new first-party MCP servers for Dynamics 365 and Dataverse (in private preview) so that business data and actions from those systems can be accessed by AI agents through the MCP. This lets custom Copilots or Azure AI agents “plug into” Dynamics/Dataverse securely without custom integration, using the standardized protocol. More broadly, Azure AI Foundry – the cloud platform for building and managing AI agents – now exposes all its hosted models and tools via a unified API that includes an MCP endpoint. In other words, any model deployed in Azure AI (OpenAI models, fine-tuned models, or HuggingFace models) can be reached through a standard MCP server for Azure AI Foundry models. Microsoft stresses that adopting open protocols like MCP (and Agent-to-Agent, A2A) will ensure agents can interact across different clouds and environments with consistent context and security controls.

Azure AI Foundry Agent Service and MCP Integration

Azure AI Foundry (the evolved Azure AI Studio) was a highlight at Build 2025, with its Agent Service reaching general availability. This fully-managed service lets developers design and deploy conversational AI agents at scale, and it now features deep integration with MCP. In practice, that means if you create an AI Agent in Azure (complete with its tools like Bing search or Azure cognitive search), you can expose that agent’s capabilities through an MCP server and use it from any MCP-compatible client or environment. Microsoft’s Azure AI Foundry blog provided a step-by-step guide on creating an MCP server that connects to your Azure AI Agent. The process involves obtaining your Azure AI project’s connection string and Agent ID, then running an MCP server module (available in Microsoft’s open-source azure-ai-foundry/mcp-foundry repository) that acts as a bridge. This MCP server essentially exposes your Azure AI Agent’s “ask” endpoint via MCP, so external clients (even a local app like Claude Desktop or GitHub Copilot in VS Code) can query your agent using natural language. Microsoft provides SDKs in multiple languages to help build these servers. For example, there are both Python and TypeScript reference implementations for an “Azure AI Agent MCP Server”. In Python, you can install the mcp package and an Azure Agents SDK, then run a provided module (azure_agent_mcp_server) which handles MCP requests by routing them to your agent’s log. These templates demonstrate best practices like how to register available agent tools and handle agent queries via the MCP JSON-RPC interface. By following these patterns, developers can build a custom MCP server that fronts their Azure AI Foundry agent – effectively creating a microservice that any MCP-aware app or bot can call to leverage that agent’s capabilities.

The Azure MCP Server for Cloud Resources (Public Preview)

Another major announcement around Build 2025 was the Azure MCP Server, a Microsoft-provided MCP server implementation designed to expose Azure’s own cloud services to AI agents. Announced in April 2025 as a public preview, the Azure MCP Server is an open-source Node.js server (available on GitHub) that comes with built-in “tools” for many Azure services. Its goal is to let an AI agent perform common Azure tasks through natural language, by calling the MCP server which in turn uses Azure SDKs/APIs.

Capabilities of Azure MCP Server (Preview) include:

• Azure Storage – list storage accounts, read/write blobs, query table storage, etc.

• Azure Cosmos DB – list databases/containers, run SQL queries on items, manage data in Cosmos NoSQL stores.

• Azure Monitor & Logs – query Log Analytics workspaces with KQL, retrieve health metrics from Azure Monitor.

• Azure App Config & Key Vault – read configuration settings and secrets/keys from Key Vault.

• Azure Resource Management – list resource groups and possibly interact with Azure resources metadata.

• Azure CLI / azd Commands – as a convenience, it can execute Azure CLI commands and even Azure Developer CLI (azd) commands, allowing agents to perform any Azure action or deploy templates via CLI calls.

All these are exposed as MCP tools (functions) that an agent can invoke. For example, an AI agent could ask “Find all VMs that had errors in the last hour,” and via the Azure MCP Server it could call a log query tool to retrieve that info from Azure Monitor logs. Or a Copilot in VS Code could use the Azure MCP Server to run azd deployment commands and suggest infrastructure-as-code templates. The Azure MCP Server authenticates to your Azure account (it supports Azure identity credentials, so it can use your logged-in user or a managed identity) and ensures the agent only accesses resources you’re authorized to use.

Deployment: Microsoft makes it easy to run the Azure MCP Server locally during development – for instance, with a one-click NPX command that sets it up in VS Code. This integrates with GitHub Copilot’s new “agent mode” in VS Code, so Copilot can call Azure tools as you chat. For production or team scenarios, you can deploy the Azure MCP Server as a service on Azure. Since it’s essentially a Node.js application, you can containerize it or host it on an Azure App Service or Azure Container Apps. Microsoft has provided an Azure Developer CLI (azd) template to scaffold and deploy the server to Azure infrastructure. The open-source repo includes instructions for cloud deployment, and because it’s stateless you can scale it out behind a load balancer if needed. In practice, many teams run it as a microservice (for example, in Azure Container Apps with a managed identity attached) so that the MCP server can securely access Azure APIs without any stored credentials. This approach – running the MCP server in Azure with managed identity – is Microsoft’s recommended best practice for production, as it keeps credentials secure and allows the service to scale on demand.

Building Custom MCP Servers on Azure

Beyond the out-of-box offerings, Microsoft expects developers will build custom MCP servers to interface AI agents with proprietary data or third-party systems. Build 2025 introduced new tools and guidance to make this easier:

• Azure Functions as MCP Servers (Preview): The Azure Functions team released an experimental MCP extension that can turn a set of functions into a remote MCP server with minimal effort. In this model, you don’t have to write the MCP protocol handling or a persistent server process yourself – you simply write Azure Functions for each “tool” you want to expose (e.g. a function to fetch an internal database record or call an external API). By adding the special attribute [MCPToolTrigger] to those functions, the Functions runtime will expose them as MCP endpoints automatically. Under the hood, the Functions MCP extension uses Azure Storage queues and SSE (Server-Sent Events) to handle the bidirectional communication between the agent (MCP client) and the function app. The result is a serverless MCP server: you deploy your function app to Azure, and AI agents can call it via the MCP protocol (over HTTPS/SSE) just like any other MCP server, but you get benefits like auto-scaling, built-in security, and integration with Azure services. This dramatically lowers the barrier to create custom tools – as one Microsoft advocate quipped, it takes the “plumbing” out of implementing the MCP spec. Note: This capability was in preview as of Build 2025 (not for production use yet), but it showcases the direction of simplified MCP server development. We now have Azure sample templates (for .NET, Python, TypeScript, etc.) that you can simply clone and deploy to get a working MCP server on Functions.

• Containerized and Code-First MCP Servers: Developers can of course build an MCP server in the language or framework of their choice using the open spec (MCP is JSON-RPC 2.0 over HTTP/SSE). Microsoft and the community have published SDKs to help with this (for example, the official Model Context Protocol SDK on npm, and libraries on PyPI). At Build, Azure AI experts demonstrated how to create a simple MCP server (e.g. in Python or Node) and host it on Azure. One reference architecture was to use Azure Container Apps to run a custom MCP server that interfaces with a corporate data source, and then use that server as a tool in an Azure AI Agent or Bot. In that scenario, the MCP server was packaged as a Docker container and deployed to Container Apps, with an Azure Managed Identity granting it permission to, say, read from Azure Blob Storage securely. The AI agent (running in Azure AI Agent Service or even as a bot in Teams) could discover the MCP server’s tools and invoke them as needed, effectively extending the agent’s abilities with custom backend logic. For higher-scale or more complex deployments, you could similarly use Azure Kubernetes Service (AKS) to host one or many MCP server instances (for example, an enterprise might run a suite of MCP microservices on AKS behind an API gateway). The key recommendation is to leverage Azure’s container hosting so you get scalability and reliability for these MCP endpoints, rather than running them on individual desktops. Microsoft has also suggested using Azure Monitor to watch these services and Azure API Management or API Center (discussed next) to catalog them for internal reuse.

Example architecture from Microsoft (Build 2025): an AI agent uses an MCP client to call a custom MCP server (via HTTPS + SSE). In this reference design, the MCP server (hosted on Azure) exposes tool actions that the agent can invoke at runtime. The Azure AI Agent Service handles function/tool calling and orchestrates the agent’s overall workflow.

Exposing Existing APIs as MCP Servers (API Management & API Center)

A significant infrastructure announcement at Build 2025 was the integration of MCP into Azure API Management (APIM) and Azure API Center. Microsoft recognized that many organizations already have robust REST APIs for their data and business logic – instead of rebuilding those as new MCP servers, why not reuse them? In preview, Azure API Management can now expose REST endpoints as MCP-compatible servers. Essentially, you can take selected operations from an API in your APIM catalog and publish them through an MCP interface (a JSON-RPC schema automatically generated). The APIM instance handles the protocol translation, so an AI agent’s MCP client can call the API operation and get results, without the service itself changing. This “no rebuild, no rehost” approach addresses a common challenge: previously, developers had to duplicate functionality or write an MCP wrapper from scratch for existing APIs. Now APIM does that for you, saving effort and ensuring that the same security and throttling rules applied to the API carry over to its MCP usage.

Equally important, Azure introduced API Center as a centralized MCP registry for the enterprise. API Center (in preview) is essentially a catalog where all your MCP servers – whether they are custom (Functions or containers) or exposed via APIM – can be registered, discovered, and governed in one place. It serves as a single source of truth for “which tools are available to my AI agents” within an organization. Teams can document each MCP server (with metadata, version history, owner contacts, etc.), and administrators can define access policies. For example, a company could use API Center to allow only certain vetted MCP servers to be visible to its internal Copilot agents, and require authentication/authorization to invoke sensitive tools. API Center also provides a search and discovery UI (with semantic search to find tools by capability) to help agent developers find the functionality they need. There’s deep integration planned with Copilot Studio and GitHub – meaning an agent developer in Copilot Studio could browse the API Center registry and pull in tools from there directly. This combination of APIM + API Center was positioned as a way to operationalize MCP at scale: you get the exposure mechanism (turning any API into an MCP server) and the management hub (cataloging and governing those servers enterprisewide). For many enterprises, this will likely be the recommended path to bring their existing assets into the AI agent ecosystem with minimal friction, while still adhering to security and compliance standards.

Best Practices for MCP Server Deployment on Azure

Microsoft’s guidance from Build 2025 can be distilled into several best practices for building and deploying MCP servers on Azure:

• Use Managed Identities and Azure AD for Security: Avoid embedding secrets or API keys in your MCP servers. If your server needs to access Azure services, assign it an Azure Managed Identity so it can obtain tokens for Azure APIs securely. Leverage the new MCP auth spec to let users consent via their Azure AD credentials to any data access – this way, agents invoke tools under a user or service identity with proper RBAC, preventing unauthorized access.

• Leverage Azure Tooling and Templates: Take advantage of Microsoft-provided templates and services that simplify MCP deployment. For instance, use the Azure Functions MCP extension (if suitable) to rapidly create serverless MCP endpoints without building an entire web service. Use the Azure Developer CLI (azd) templates or Azure-Samples on GitHub for MCP to scaffold projects in your preferred language. These templates incorporate Azure best practices (CI/CD, environment config, etc.) so you can focus on tool logic.

• Register and Govern MCP Servers: Maintain an inventory of your MCP servers. In a single-team scenario this might be a JSON registry or the open-source community registry, but in an enterprise, Azure API Center is recommended as the centralized registry. This allows you to version your MCP tools, deprecate or update them systematically, and control discovery (ensuring only trusted MCP endpoints are used by your AI agents). It also aids discoverability – developers can search the registry for existing tools before creating new ones, fostering reuse.

• Monitor and Optimize: Treat your MCP servers as production APIs. Use Azure’s monitoring (Application Insights, Azure Monitor) to track usage, latency, and errors for your MCP calls. Microsoft’s Azure AI Foundry includes Observability features to trace agent-tool interactions with metrics for performance, quality, cost, and safety. By monitoring these, you can identify slow or failing tools and improve them. Also consider setting up rate limits or usage policies either in your MCP server code or via APIM, especially if exposing critical backend systems, to prevent an agent from overloading your resources.

• Design for Compatibility and Streaming: Ensure your MCP server adheres to the MCP protocol spec (JSON-RPC 2.0) exactly, so that any MCP-compliant client (whether it’s a Microsoft Copilot, Semantic Kernel agent, or third-party AI agent) can use it. This includes implementing Server-Sent Events (SSE) for streaming responses when tools perform long-running tasks or stream data. Microsoft’s tooling (the MCP SDKs, Functions extension, APIM integration) all support SSE out of the box. Streaming is important for a good user experience – e.g. an agent can show partial progress or stream a long answer as it’s generated.

• Utilize Reference Architectures: Microsoft shared several reference patterns – from simple local dev setups to full-scale cloud deployments. A common pattern is deploying an MCP server behind an Azure API Management facade. This gives you enterprise features like authentication, caching, logging, and even transformation policies, on top of your MCP server. Another pattern is embedding MCP servers within internal applications: for example, Windows will allow apps to package built-in MCP servers so that Windows users’ agents can discover app functionality. On Azure, consider grouping related MCP tools into a single server for efficiency (each MCP server can host multiple “tools/functions”). Also, keep the MCP server stateless if possible – this allows easy scaling and redeployment. If state is needed (e.g. long sessions), use external storage or Azure Cache to maintain it.

By following these practices and using the newly announced Azure services, developers can confidently build and deploy MCP servers that extend their AI agents with powerful new abilities. Microsoft’s Build 2025 updates – from Azure AI Foundry’s agent integration to API Management’s MCP bridging – provide a rich toolset to make this process easier, more secure, and enterprise-ready. In summary, Azure is evolving into a first-class platform for MCP-based AI extensions, enabling organizations to connect their AI copilots to the wealth of data and services they have, all while maintaining control and governance. With Azure’s reference architectures and upcoming features, deploying an MCP server is becoming as straightforward as deploying a web service – bringing us closer to the vision of AI agents seamlessly interoperating across the cloud.