Catalogue › Microsoft Foundry › mcp-integration

MCP integration

Integrates Model Context Protocol servers with Microsoft Foundry agents safely - vetting who runs each server, allowing only the tools needed, authentication and identity, approval for consequential calls, pinning versions and handling changes in what a server offers. Use when a team wants to connect an MCP server to a Foundry agent, when an internal service should be exposed over MCP, or when a connected server changes its tools.

Department

Microsoft Foundry

Lifecycle

Deliver, Assure, Improve

Maturity

builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

ai-foundry, azure, entra

Editions

starter, scale, enterprise

Reviewers

security-privacy, design-authority

Status

draft

Copilot Cowork

Microsoft Foundry plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

The Model Context Protocol lets an agent discover and call tools offered by a server, which makes it quick to give a Foundry agent new capabilities and equally quick to give it capabilities nobody reviewed. This skill decides whether a given server may be connected, which of its tools the agent may use, under which identity, with what approval, and how changes on the server side are noticed before they change the agent's behaviour. MCP integration goes wrong when a public server is connected because a demonstration looked useful, when every tool a server advertises is allowed by default, and when the server's owner changes a tool description that the agent then follows.

When to use

• A team wants to connect an existing MCP server, internal or external, to a Foundry agent.
• An internal service is to be exposed over MCP so several agents can use it.
• A connected server has added, removed or changed tools, or changed its owner or hosting.
• A prototype agent uses MCP servers informally and needs a production integration design.
• Reviewers ask who runs a server the agent depends on and what data it sees.

When not to use

• Designing the contract of a function the organisation hosts itself for one agent - use ai-foundry:foundry-tool-design.
• Deciding which capabilities the agent needs at all - use ai-foundry:foundry-agent-architecture.
• Choosing integration patterns across the estate, of which MCP is one option - use ai-architecture:ai-integration-patterns.
• Adding MCP servers to a Copilot Studio agent - use copilot-studio:studio-actions-and-tools.
• Reviewing connectors, tools and MCP servers at the security gate - that is the reviewer skill security-privacy:connector-review.

Questions to ask first

1. Who builds, hosts and operates the server, under what terms, and what happens to the data the agent sends it?
2. Which of the server's tools does the agent actually need, and which of those read, write, send or spend?
3. How does the server authenticate the agent and, where relevant, the user, and whose permissions apply to each call?
4. How will the organisation learn that the server's tools, descriptions or behaviour have changed?
5. What should the agent do when the server is slow, unavailable or returns something unexpected?

Required inputs

• The agent architecture with its tool inventory and identity approach, on the foundry-solution-design template.
• Documentation of the server: owner, hosting location, tool list, authentication options and versioning.
• The data classification of what the agent would send to and receive from the server.
• Agreement from the owner of any system the server acts on.

Where the server's owner, hosting or data handling cannot be established, mark them [To confirm: ...] and do not connect it. A server nobody can vouch for is treated as untrusted, whatever its popularity.

Decision framework

Allow only named tools. A server connection that exposes every advertised tool is treated as the highest effect class among them.

Practitioner approach

Establish provenance before capability. Find out who wrote the server, who runs it, where it is hosted and what it does with requests. An MCP server can see everything the agent sends it, including user questions and retrieved content, and can return text the model will read as context. Treat a server you cannot vouch for as an untrusted party in the conversation. For public servers, the usual answer is to rebuild or host a reviewed copy inside the organisation's governance rather than connecting to someone else's endpoint.

List the server's tools and decide which the agent needs. Allow those by name and block the rest, even if the platform would expose everything by default. Read each tool's description as the model will read it; a description written to attract the model's attention, or one that contains instructions, is a warning sign. Remove tools whose descriptions overlap with the agent's other tools.

Design identity per tool. Where the server reaches organisational data, prefer user-delegated access so the user's permissions apply. Where a service identity is unavoidable, scope it to the least the allowed tools need and record why. Never place long-lived keys in agent configuration; use a managed secret store and identities designed with ai-engineering:secrets-and-identity.

Require approval for consequential calls. Any tool that writes, sends, deletes or spends should need a person to confirm before it runs, with the arguments shown in plain language. For tier 2 and above, approval should be the default for every call until evaluation shows read-only tools behave predictably.

Control change. Pin to a known server version or record a fingerprint of its tool list and descriptions, and check it on a schedule and before each release. A new tool, a changed description or a new required scope is a change to the agent and goes through review. Agree with internal server owners that they announce changes; for external servers, assume they will not.

Plan for failure. Set timeouts, decide what the agent tells the user when a server is unavailable, and stop the agent retrying in a loop. Trace every MCP call with server, tool, version and latency so problems can be diagnosed.

Record the integration in the MCP section of the solution design. State what remains uncertain, such as how an external server handles data after a call, which only contract terms can settle.

Outputs

• An MCP server register entry in the foundry-solution-design template per server: owner, hosting, terms, allowed tools, effect class, identity, approval rule, version pin and change check.
• An allow-list of tools per agent with the reason each is needed.
• Test cases for each allowed tool, including injected content in server responses, handed to ai-engineering:ai-solution-testing.

Microsoft platform considerations

Foundry Agent Service and the wider Microsoft agent platforms are adding MCP support quickly, and the available authentication methods, approval settings, hosting options and preview status vary and change. Check the current source records before relying on a capability, such as per-tool allow-listing or user-delegated authentication to an MCP server. Where the same server is used by Copilot Studio or Microsoft 365 agents, align the review so the server is assessed once and its approved tool list is shared.

Adoption considerations

Not applicable for most integrations, because users experience the agent rather than the server. Where approvals are required, write the approval prompt with the business owner so people understand what they are confirming.

Knowledge considerations

Where an MCP server supplies knowledge rather than actions, its content needs an owner and freshness route like any other source, and its retrieval behaviour should be checked with ai-foundry:retrieval-design.

Security and privacy considerations

An MCP server is both a data recipient and a source of untrusted text, so it carries exfiltration and indirect injection risk. Confirm what data leaves the organisation, apply least privilege and user-delegated access, and require approval for consequential calls. security-privacy:connector-review reviews each server from tier 2, and personal data sent to an external server needs the DPO's view.

Responsible AI considerations

Actions taken through an MCP tool are the agent's actions in the eyes of the people affected. Consequential calls need a human checkpoint agreed with responsible-ai:human-oversight, and users should be able to see which external service acted on their behalf.

Evaluation requirements

Evaluate tool selection, argument correctness and refusal to call disallowed tools, including cases where a server response contains instructions. Re-run the evaluation whenever the server's tool list or descriptions change.

Value measures

Track successful task completion through MCP tools, failed or timed-out calls and approval decline rates at solution level, owned by the solution owner. Count servers connected without review as a governance measure.

Scale notes

Starter

Connect only internally built or contracted servers, allow a small number of read-only tools, and check the tool list manually before each release.

Scale

Keep a shared register of reviewed MCP servers with approved tools, so agents reuse reviewed integrations instead of repeating the work, and automate the tool-list change check.

Enterprise

Run internal MCP servers as governed products with owners, versioning and change notice, route all external servers through a central review, and monitor for unregistered server connections.

Hand-offs

• To security-privacy:connector-review for the gate review of each server.
• To ai-foundry:foundry-tool-design when a server tool should be replaced by an organisation-built function.
• To ai-engineering:secrets-and-identity for credentials and identities.
• To ai-foundry:foundry-observability so MCP calls are traced.
• To platform-governance:ai-solution-inventory to record server dependencies.

Reviewer gates

From risk tier 2, security-privacy reviews provenance, data flows, identity and approval rules for each server, and design-authority checks the integration conforms to the reference architecture. A public server connected to production with organisational data is a blocking finding at any tier.

Failure modes

• A public server is connected for convenience, and user questions and retrieved documents flow to an unknown party.
• Every advertised tool is allowed, and the agent calls a delete operation nobody knew the server offered.
• A server owner rewrites a tool description, and the agent starts calling it for requests it was never meant to handle.
• A slow external server makes the agent retry repeatedly, exhausting quotas and leaving users waiting.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Connect a production agent to an MCP server whose owner, hosting and data handling are unknown.
• Allow every tool a server advertises instead of a named allow-list.
• Let a write, send, delete or spend tool run without approval and an audit trail.
• Treat a change to a server's tools or descriptions as anything other than a change to the agent.