MCP for Azure AI Agents: Architecture, Auth, and Real-World Use Cases

TL;DR

Microsoft’s Integrate MCP Tools with Azure AI Agents module shows how to connect Foundry agents to Model Context Protocol (MCP) servers so the agent can dynamically discover and call external tools at runtime. The module is intermediate, spans 7 units, and focuses on three practical skills: understanding MCP server/client roles, wrapping MCP tools as async functions, and building agents that can call those tools during execution. Microsoft Foundry supports MCP alongside OpenAPI and A2A tools, with authentication options such as project connections, managed identity, OAuth passthrough, and unauthenticated access where appropriate.

Why MCP matters

A lot of AI agent demos stop at “the model can answer questions.” That is useful, but not enough for real systems. The moment an agent needs to inspect a service, fetch live business data, or trigger a workflow, it needs a clean way to reach the outside world. That is where MCP becomes important. Microsoft describes MCP as an open standard for connecting applications to tools and contextual data, and positions it as a way to extend Foundry agents with external tools and data sources.

Practically speaking, MCP is like giving your agent a universal adapter instead of a bunch of one-off cables. Without it, every integration becomes a custom special case. With it, the agent can discover tools from an MCP server and use them in a more consistent way. Microsoft’s Foundry tool catalog explicitly says MCP is best for tools shared across multiple agents or maintained by another team.

Background: what Microsoft is teaching in this module

The Microsoft Learn module Integrate MCP Tools with Azure AI Agents is designed for AI Engineers, Developers, Solution Architects, and Students at the Intermediate level. Microsoft says the module’s purpose is to enable dynamic tool access for Azure AI agents and seamlessly integrate MCP-hosted tools into agent workflows. The learning objectives are tightly focused: explain MCP server and client roles, wrap MCP tools as asynchronous functions and register them with Azure AI agents, and build an agent that dynamically accesses and calls MCP tools during runtime.

That scope is telling. Microsoft is not teaching MCP as an abstract protocol lesson. It is teaching MCP as an engineering pattern for production agents. If you already know how to deploy generative AI models in Microsoft Foundry and you have programming experience, this module is meant to move you from “I understand agents” to “I can wire agents into real tools.”

Core concept 1: MCP is the tool bridge

Microsoft’s Foundry docs define MCP as an open standard that lets applications provide tools and contextual data to LLMs. In Foundry Agent Service, connecting to an MCP server extends agent capability with external tools and data sources. That connection is performed through the MCP tool, which lets the agent use tools hosted on remote MCP server endpoints.

This is a strong architectural choice for enterprise AI because it separates the agent brain from the tool surface. The model reasons. The MCP server exposes capabilities. The Foundry agent orchestrates the interaction. That separation is useful when different teams own different systems, or when several agents need to reuse the same tool set. Microsoft explicitly calls out that MCP is a good fit for shared tools and tools maintained by another team.

Core concept 2: tools are discovered, invoked, and approved

The module teaches three important MCP behaviors. First, the agent needs to understand the roles of the MCP server and client in discovery and invocation. Second, MCP tools can be wrapped as asynchronous functions and registered with Azure AI agents. Third, the agent can dynamically access and call those tools during runtime.

Foundry’s MCP documentation also emphasizes tool call review and approval. Microsoft says the article covers how to add a remote MCP server as a tool, authenticate via a project connection, review and approve tool calls, and troubleshoot common integration issues. The same docs recommend using an allow list, requiring approval for high-risk operations, reviewing tool names and arguments before approval, and logging approvals for auditing and troubleshooting.

That matters because agents should not be treated like autonomous black boxes when they can act on real systems. In a production setting, MCP is not just about connectivity; it is about controlled connectivity.

Core concept 3: Foundry supports several integration paths

One thing I like about Microsoft’s current Foundry approach is that MCP is not presented as the only tool option. Foundry Agent Service also supports OpenAPI tools for external HTTP APIs and A2A for agent-to-agent communication. Microsoft’s tool catalog positions MCP for shared or externally maintained tools, OpenAPI for APIs described by OpenAPI 3.0 or 3.1, and A2A for cross-agent communication. There is also a Toolbox preview that bundles multiple tools into a single MCP endpoint.

That gives you a useful design decision tree:

• Use OpenAPI when you already have a clean REST API surface.
• Use MCP when you want standardized tool exposure and discovery.
• Use A2A when the right abstraction is another agent, not a direct API.
• Use Toolbox when you want to package multiple tools into one reusable endpoint.

For a practitioner, that flexibility is huge. It means you can choose the integration pattern that matches the underlying system instead of forcing every backend through one adapter style.

Authentication is not an afterthought

Microsoft’s Azure Functions guidance for connecting an MCP server to Foundry Agent Service shows several authentication modes: key-based, Microsoft Entra, OAuth identity passthrough, and unauthenticated. For Entra-based connections, the agent can use a managed identity. For OAuth passthrough, the agent prompts the user to sign in and uses the returned access token. Unauthenticated access is only for public information.

This is more than implementation detail. It is a security model. MCP is useful precisely because it can connect to valuable internal systems, but that also means you need to be deliberate about identity and trust. Microsoft’s docs are explicit that users should carefully review and track which MCP servers they add, rely on trusted providers, and audit the data shared with remote servers.

A simple architecture pattern for MCP-based agents

A clean way to think about an MCP-enabled agent is:

User request
   ↓
Foundry agent
   ↓
Reasoning + policy check
   ↓
MCP tool discovery
   ↓
Authenticated MCP call
   ↓
Structured tool result
   ↓
Agent response or next action

That pattern works because it keeps responsibility in layers. The agent is responsible for reasoning and routing. The MCP server is responsible for tool exposure. Authentication is handled explicitly. And the tool result comes back in a format the agent can continue to reason over. This is exactly the kind of decoupling Foundry’s MCP support is designed for.

A good rule of thumb: keep MCP tools small and purposeful. The better the tool contract, the more reliable the agent behavior. This is also why Microsoft recommends reviewing tool names and arguments before approval and logging approvals for auditability.

Practical use cases

One strong use case is an internal knowledge-and-action agent. The agent can answer questions, but when it needs live information from an internal system, it uses MCP to reach a server that exposes that capability. Because MCP is standardized, the same server can potentially serve multiple agents across a team or organization.

Another useful case is shared enterprise tooling. Suppose one team owns a compliance or policy-checking service, and several agents across the company need access to it. MCP is a natural fit because Microsoft explicitly says it is best when tools are shared across multiple agents or maintained by a different team.

A third scenario is governed workflow automation. Imagine an agent that can inspect a ticket, check a resource, and then propose an action, but requires approval for the write step. Microsoft’s guidance on approval review, allow lists, and logging fits that pattern well. In enterprise settings, that mix of automation and human control is usually the difference between an interesting demo and a deployable system.

A quick example of how Microsoft frames the implementation

Microsoft’s docs show that Foundry Agent Service can connect to MCP servers from the Foundry portal and that the specific setup depends on the authentication mode. In the Azure Functions walkthrough, the process includes selecting an agent in the Foundry portal, adding a custom MCP tool from the Tools dropdown, entering the remote server endpoint, choosing the auth method, and saving the configuration. The example endpoint format includes the /runtime/webhooks/mcp path for the Azure Functions-based MCP server.

That is a good sign for developer experience. The platform is not expecting you to hand-stitch every protocol detail at the application layer. Instead, it gives you a repeatable way to connect a server and an agent, then test the tool flow. Microsoft also says the module covers integration into agent workflows and dynamic runtime calls, which suggests that testing is part of the learning path, not an afterthought.

Challenges and trade-offs

The biggest advantage of MCP is also its biggest operational risk: external tool access. The more tools an agent can see, the more important tool selection, permissioning, and auditability become. Microsoft’s best-practice guidance to use allow lists, require approval for high-risk operations, and log tool calls is not optional in serious deployments.

Latency is another trade-off. Any remote tool call adds network overhead, and Microsoft’s documentation includes a non-streaming MCP timeout warning in the MCP server guidance. That is a practical reminder that agent design must account for the performance characteristics of the tools beneath it.

There is also an architecture decision to make: if your API is already well described in OpenAPI, MCP may not be necessary for that specific integration. If you need agent-to-agent delegation, A2A may be a cleaner boundary. MCP is powerful, but it is not a universal hammer. Foundry’s tool catalog exists precisely because different problems need different integration shapes.

Future outlook

MCP looks increasingly like a standard layer for enterprise agent ecosystems. Microsoft’s Foundry docs now position MCP alongside OpenAPI and A2A in the core tool catalog, and the platform supports private tool catalogs, server registration, and managed connections for organization-scoped use. That suggests a future where tool discovery is less about one-off integrations and more about governed, reusable capability publishing.

The bigger trend is clear: agents are moving from isolated chat experiences to networked operational systems. MCP is one of the connective tissues that makes that possible. In a Microsoft ecosystem, it is especially useful because it aligns well with Foundry Agent Service, Azure Functions, Entra identity, and the broader enterprise governance story.

Conclusion

If you are building AI agents on Azure, MCP is one of the most important practical ideas to learn right now. Microsoft’s module teaches the right fundamentals: understand the protocol roles, wrap tools for agent use, connect them through Foundry, and handle approval and authentication with care. The core message is simple: an agent becomes genuinely useful when it can discover and use the right tools at the right time, under the right controls.

That is the difference between an AI demo and an AI system.