Foundry Agents Get MCP Tooling — And Microsoft Finally Says the Quiet Security Part Out Loud

Foundry Agent Service supporting MCP is not the headline. The headline is that Microsoft’s documentation now reads like someone has finally accepted the security implications of MCP becoming the default tool layer for enterprise agents.

The new Microsoft Learn guidance explains how Foundry agents connect to remote Model Context Protocol servers across Python, C#, JavaScript, Java, REST, Basic agent setup, and Standard agent setup. It covers public endpoints, private endpoints, project connections for credentials, Foundry Toolboxes as MCP-compatible endpoints, approval gates, and limitations such as a 100-second timeout for non-streaming MCP tool calls. That sounds like plumbing because it is plumbing. It is also the part of the stack that will decide whether production agents are useful systems or beautifully documented footguns.

MCP gives agents a common way to discover and call tools. Foundry support gives Microsoft customers a managed place to wire those tools into hosted agents. But the useful part of the docs is the caution: non-Microsoft MCP servers may receive prompt content, custom headers can carry sensitive authentication material, and developers remain responsible for tool selection, data handling, and compliance. Translation: the protocol standardizes the door. It does not decide who should walk through it.

The architecture is taking shape: agents, tools, credentials, policy

The Foundry pattern is clear. Agents run in Microsoft’s agent service. Tools are exposed over MCP. Credentials should be stored in a Foundry project connection instead of application code. Public MCP endpoints can be used with Basic and Standard setups. Private MCP endpoints require Standard Agent Setup, private networking, and a dedicated MCP subnet in a virtual network. Microsoft’s validated private configuration uses Azure Container Apps with internal-only ingress on a subnet delegated to Microsoft.App/environments.

That is a lot of detail for a how-to page, and it is exactly the detail practitioners need. “Connect your agent to tools” is easy to say. Production implementation is about where secrets live, which network boundary applies, who owns the endpoint, how tools are allowlisted, which actions require approval, and where logs land after something goes wrong. Foundry’s MCP docs are useful because they expose those seams instead of pretending agent tooling is a magic connector catalog.

The sample code is also revealing. Microsoft shows an MCPTool pointed at GitHub’s https://api.githubcopilot.com/mcp, with server_label="api-specs", require_approval="always", a project_connection_id, and gpt-5-mini as the sample model. The model choice is not the interesting part. The interesting part is approval as a first-class configuration decision. That is where enterprise MCP either becomes governable or becomes another pile of SaaS tokens with better branding.

Microsoft recommends allowed_tools, approval for high-risk operations, review of requested tool names and arguments, and logging approvals/tool calls for audit. Those are not optional niceties. They are the minimum viable control plane for an agent that can call external systems. If the agent can write, delete, send, trigger, deploy, purchase, or expose data, the tool call deserves the same scrutiny as any other production action.

Toolboxes are the sleeper feature

The most important concept in the documentation may be Foundry Toolboxes. They can bundle Web Search, Code Interpreter, File Search, Azure AI Search, MCP servers, OpenAPI tools, and Agent-to-Agent connections into a single MCP-compatible endpoint. They can then be consumed by Foundry Agent Service, Microsoft Agent Framework, LangGraph, GitHub Copilot SDK, and other MCP-enabled clients.

That looks like convenience. It is really governance architecture.

MCP by itself standardizes how an agent talks to tools. It does not curate the tool catalog, inject credentials safely, version capability bundles, enforce organizational policy, or explain why one team’s “helpful automation server” suddenly has access to half the company. A Toolbox can become the reviewed contract: here is the approved set of capabilities for this workflow, here is how credentials are managed, here are the risky tools, here is what gets logged, and here is the version that was promoted to production.

That matters because tool sprawl is the next predictable agent failure mode. First teams connect one tool. Then five. Then every SaaS system with an API gets wrapped in MCP because the demo worked. Eventually the agent sees too many similar affordances, calls the wrong one, leaks sensitive context to a third-party server, or racks up cost by searching and calling tools it did not need. Toolboxes do not solve that automatically, but they create a place where the mess can be managed.

The 100-second non-streaming timeout is another useful reality check. Long-running MCP calls should not be giant opaque jobs disguised as tools. If a tool needs minutes to complete, it should probably return a job handle, emit progress, or split work into bounded operations. Agents should orchestrate deterministic capabilities; they should not smuggle entire business processes through one request while every observer waits for a mystery response. The timeout nudges builders toward healthier architecture whether they appreciate it or not.

Production MCP is security engineering, not a JSON paste party

The broader MCP ecosystem has the same tension. The reference server repository warns that examples are educational and not necessarily production-ready. The MCP specification’s trust-and-safety guidance treats tools as serious: they can create arbitrary data access and code execution paths, so hosts should provide consent, authorization, access controls, and privacy protections. Microsoft’s docs now echo that operationally.

The practical recommendation is blunt: never connect a production Foundry agent to a broad remote MCP server without an allowlist, approval policy, network boundary, and audit trail. Use allowed_tools like IAM permissions. Treat require_approval="always" as the default for write-capable tools until you can prove a narrower policy is safe. Store credentials in project connections, not code. For private tools, use Standard setup and private networking rather than exposing an endpoint because the prototype needed it by Friday.

Also assume that third-party MCP servers may receive more sensitive context than intended. Prompt content, tool arguments, headers, and retrieved data can all become part of the interaction surface. That does not mean “never use third-party MCP.” It means classify the data before connecting the server, document what leaves the Microsoft boundary, and test prompt-injection and tool-confusion scenarios before users do it for you.

For engineering leaders, the action item is to create an MCP review checklist now. Who owns the server? What tools are exposed? Which are read-only? Which mutate state? What credentials are injected? What approvals are required? What data classes may appear in prompts or arguments? Where are tool calls logged? What happens when a tool times out? Which version of the Toolbox is deployed? If those questions sound bureaucratic, they are also the questions incident response will ask later with less patience.

Foundry MCP support is a meaningful step because it turns a fast-moving protocol into something Azure customers can wire through known concepts: projects, connections, private networking, approvals, and hosted agents. The skeptical take is that MCP will only be as safe as the weakest server and broadest allowlist in the chain. The optimistic take is that Microsoft is at least giving builders the right places to put the controls. Use them. The JSON was never the product.

Sources: Microsoft Learn — Connect agents to Model Context Protocol servers, Model Context Protocol specification, Model Context Protocol servers repository, Microsoft Foundry Build 2026 coverage