If you’ve been evaluating AI agents for enterprise use, you’ve likely started hearing about Model Context Protocol, usually shortened to MCP. It shows up in architecture discussions, vendor documentation, and agent framework comparisons, often without a clear explanation of what problem it’s actually solving.
This post explains what MCP is, why it matters for how enterprises connect agents to their tools and data, and what the governance questions are before you decide which MCP servers an agent can call.
Key takeaways
- Model Context Protocol (MCP) is an open standard that defines how AI agents connect to external tools, data sources, and services. It gives agents a consistent way to call tools without custom integration code for each one.
- MCP works on a client-server model: an MCP server exposes tools, and an agent (through its host or framework) calls them. The agent doesn’t need to know how the tool is implemented, only what it does.
- Microsoft Foundry supports MCP as a first-class integration. Agents can connect to any compliant MCP server, internal or third-party.
- Not all MCP servers are equally trustworthy. Microsoft says it doesn’t test or verify third-party MCP servers, so treat tool descriptions and results as untrusted input.
- Approval requirements, least-privilege credentials, and scoped connections are the key controls before an agent calls an MCP server in production.
What is Model Context Protocol?
MCP is an open standard, originally developed by Anthropic, for how language models interact with external tools and context sources. Before MCP, connecting an agent to an external system (a database, an API, a file store) required writing custom integration code for each system and re-implementing that logic every time the agent framework or the external system changed.
MCP defines a standard interface. An MCP server exposes a set of tools with descriptions and input/output schemas. Any MCP-compatible client (an agent, a framework, an IDE) can discover and call those tools without knowing anything about the underlying implementation. The protocol handles the communication; the developer handles the tool logic inside the server.
The practical effect is that the same MCP server can be reused across different agents, different frameworks, and different host environments. A server that exposes your internal knowledge base can be called by an agent in Microsoft Foundry, a developer assistant in VS Code, or a custom agent in a third-party framework, without rebuilding the connection for each one.
Microsoft’s Azure MCP Server implements this standard for Azure resources, exposing tools that let agents interact with Azure services through natural language. See the Microsoft Learn documentation on the Azure MCP Server for the full list of capabilities and how authentication works through Entra ID.
Why does MCP matter for AI agents in the enterprise?
The alternative to MCP is function calling with custom integrations: each tool the agent needs gets its own authentication setup, its own schema definition, and its own maintenance burden as the tool’s API changes. That works for a small number of tools, but it doesn’t scale when agents start needing access to many systems, and enterprise agents typically do.
MCP shifts the architecture. Instead of agents knowing about individual tools, agents know about MCP servers, each of which manages a category of tools. Microsoft Foundry extends this with toolboxes, which bundle multiple tools and MCP servers into a single MCP-compatible endpoint. An agent connects to that one endpoint and discovers what’s available. When a tool changes, you update the toolbox, not each agent.
This matters for governance as much as it does for development efficiency. When tools are centrally managed, their configuration lives in one place instead of inside each agent. An audit of what tools an agent can call is a single configuration to review, not a scan of multiple integration files.
For enterprise teams evaluating MCP, the relevant question isn’t whether to use it. It’s which MCP servers to trust and under what conditions. See the Microsoft Learn documentation on using MCP with Foundry agents for how connections, authentication, and approval requirements work in practice.
If your first agent needs to answer from internal documents, start with retrieval and access. Our AI on Your Data pilot grounds answers in one of your document libraries, cites the source for every answer, and limits access to the people you authorize.
How do we decide which MCP servers an agent may call?
This is the governance question that most architecture discussions skip over, and it’s worth taking seriously before agents go to production.
The core issue is that MCP server descriptions and tool results are text that the agent reads and acts on. A malicious or poorly constructed tool description can influence agent behavior in ways the developer didn’t intend. This is the prompt injection vector at the tool layer. Microsoft’s own documentation explicitly recommends treating MCP tool descriptions and results from remote MCP servers as untrusted input.
A practical framework for evaluating which MCP servers an agent may call:
Who operates the server and under what terms? An internal MCP server you’ve built and control is different from a third-party server run by a vendor whose data handling practices you haven’t reviewed. Apply the same due diligence you would to any external service that processes business data.
What data will the tool receive? Every MCP tool call potentially sends data to the server: the user’s query, content from earlier in the conversation, or other details the model includes in the tool arguments. If that data includes customer records, proprietary content, or regulated information, the server receiving it needs to meet the same compliance bar as any other system handling that data class.
What can the tool do, and can it be undone? Read operations carry lower risk than write operations. For any tool call that modifies or creates data, requiring approval before execution adds a checkpoint that limits the damage from an unexpected action.
A deployment guide for AI agents on Azure covers the broader deployment model for Foundry agents, including how to structure the connection and tool configuration. For identity, permissions, and logging, see AI agent security on Azure.
Frequently asked questions
What is Model Context Protocol (MCP)?
MCP is an open standard for how AI agents connect to external tools, data sources, and services. It defines a client-server interface so agents can discover and call tools without custom integration code for each tool. An MCP server exposes a set of tools with descriptions and schemas; an MCP-compatible agent calls them through the standard interface.
How is MCP different from function calling?
Function calling is a capability built into most large language models that lets the model request a specific function to be run with specific arguments. MCP is a standard for how those tools are exposed and discovered. With function calling alone, each tool needs to be defined and integrated individually for each agent. With MCP, a server exposes many tools through one endpoint, and any MCP-compatible agent or framework can call them without additional integration work.
Does Microsoft Foundry support MCP?
Yes. Foundry agents can connect to any MCP-compliant server, internal or third-party, using the MCP tool. Foundry toolboxes extend this by bundling multiple tools and MCP servers into a single MCP-compatible endpoint that agents can reuse.
Are third-party MCP servers safe to use?
Not by default. Microsoft explicitly notes that it doesn’t test or verify third-party MCP servers. Tool descriptions and results from any MCP server should be treated as untrusted input that could contain prompt injection attempts. Evaluate any external MCP server the same way you would evaluate any external service receiving business data: who operates it, what data it receives, and what it can do with that data.
How do we control which MCP servers an agent can call?
In Microsoft Foundry, connections store the authentication details for each MCP server, and you configure which connections an agent can use. You can restrict tool calls to a specific list using the allowed_tools parameter, and you can require approval before an agent executes any tool call or specific ones. Apply least-privilege credentials on each connection: a tool that only reads should not hold a write-capable credential.
Keep reading
AI Agent Security: Identity, Permissions, and Blast Radius
When an AI agent runs in a production environment, it doesn't just answer questions.
Enterprise AI Agents on Azure: Where to Start
The term "AI agent" has moved from research papers to enterprise roadmaps faster than most technology concepts do.
What It Costs to Run AI on Azure
When organizations start evaluating enterprise AI on Azure, one of the first questions IT finance and technology leaders ask is...