Toolboxes: many tools, one governed MCP endpoint
Lesson 3 of 5 in Microsoft Foundry Agent Service, Three Ways to Run an Agent.
Every agent platform eventually hits the same wall. Ten agents need the same eight tools; each tool needs credentials; each team wires its own; nobody can answer “which agents can read the CRM?” and nobody can rotate a secret without breaking something.
Foundry’s answer is the Toolbox: a curated group of tools published behind a single managed MCP-compatible endpoint, with authentication, governance and versioning handled at the toolbox rather than in each agent.
Consume — “Foundry-homed, not Foundry-bound”
That phrase is Microsoft’s, and it is the most consequential design choice here. Because the endpoint is MCP-compatible, non-Foundry runtimes consume the same toolbox: Microsoft Agent Framework, LangGraph, the GitHub Copilot SDK, or any custom MCP client.
So a toolbox is not a lock-in surface — it is the governed tool layer for your whole estate, including agents running somewhere else entirely. The toolbox MCP endpoint also supports long-running operations through MCP tasks (preview).
Govern — credentials the agent never sees
Toolbox governance covers centralized credential injection, token refresh, and policy enforcement via Microsoft Entra ID and OAuth identity passthrough. Consuming agents do not manage per-tool credentials.
Read that as a least privilege story. The agent holds an identity; the toolbox holds the tool credentials and decides, per caller, what a call is allowed to become. Rotating a secret is a toolbox operation, not a fleet-wide redeploy.
Connection auth types documented for MCP servers and tools: none, custom keys, OAuth2 (a Foundry-managed OAuth app or your own registration), user Entra token, project managed identity, and agentic identity — the agent’s own Entra identity.
Govern — guardrails on tool inputs and outputs
Guardrails (Responsible AI policies) can be applied at the toolbox level, to tool inputs and outputs. That placement matters more than it looks: a tool output is untrusted content arriving from the outside world, and it is the classic vector for tool-output poisoning and indirect injection.
In Foundry’s guardrails model a guardrail is a named collection of controls, and there are four intervention points: user input, tool call (preview, agents only), tool response (preview, agents only), and output. The two middle ones exist precisely because agents read and act on tool traffic.
Discover — tool search (preview), for when you have hundreds of tools
A toolbox can hold far more tools than fit sanely in a context window. Tool search (preview) hides tools by default and exposes only two meta-tools — tool_search and call_tool — so the model finds what it needs on demand. Critical tools can be pinned or auto-pinned.
Microsoft cites three motivations, and all three are real measurable problems: token cost, context capacity, and tool-selection accuracy. Past a few dozen tool definitions, models get worse at choosing, not just more expensive.
Build — the connector shortcut (preview)
The Foundry Tools Catalog offers over 1,000 connectors. Adding a connector to an agent creates a managed MCP server that Foundry provisions and manages in the account’s Connector Namespace.
This was public preview when checked in September 2026 — no SLA, and Microsoft does not recommend preview features for production. Excellent for prototyping the integration you will later own deliberately.
Interactive sorting exercise: Where does each concern belong on this platform — the toolbox, the agent definition, or a guardrail control? Same question you should ask on any platform: who owns this, and can one team change it without a fleet redeploy?
Tool: Tool Permission Lab — Practise the least-privilege decisions a toolbox forces you to make explicit: which agent gets which tool, with whose credentials, and what the blast radius is when the model is wrong.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.