Building AI agents sounds straightforward until you actually do it. You need an agent to onboard a new employee. It has to create an Entra ID account, provision GitHub access, spin up cloud resources, create tasks in Azure DevOps, and send a welcome message in Teams. Five tools. Five different authentication models. Five different teams are managing those tools.
Now multiply that across every agent your organization is building.
That’s the problem Microsoft is addressing with Toolboxes in Foundry, now available in public preview.
What Toolboxes Actually Do
A Toolbox is a named, reusable bundle of tools managed in Microsoft Foundry. You define your tools once, configure authentication centrally, and expose everything through a single MCP-compatible endpoint. Any agent that can consume an MCP endpoint can use a Toolbox — regardless of the framework it was built on.
The endpoint looks like this:
https://zava.services.ai.azure.com/api/projects/<project>/toolbox/<toolbox-name>/mcp?api-version=v1
One endpoint. Every tool in the bundle. No per-tool wiring.
Today, Toolboxes support built-in tools like Web Search, Code Interpreter, File Search, and Azure AI Search. They also support Model Context Protocol (MCP), Agent-to-Agent (A2A), and OpenAPI integrations. Authentication is handled centrally through OAuth identity passthrough and Microsoft Entra managed identity — agents don’t manage credentials themselves.
Why This Matters for DevOps Teams
The problem Toolboxes solve isn’t just developer friction. It’s an operational and governance problem.
When every team wires its own tools, credentials get duplicated. Governance is inconsistent. There’s little visibility into which tools exist across the organization, who’s using them, or whether they’re being called correctly. Security teams can’t enforce consistent policies when every agent has its own integration pattern.
Toolboxes shift that model. Tool owners define and publish once. Consuming teams connect once. And when a Toolbox is updated, agents using it don’t need to change their code.
Microsoft has organized the Toolbox lifecycle into four pillars: Discover, Build, Consume, and Govern. Build and Consume are available today. Discover (which helps teams find existing approved tools rather than rebuild them) and Govern (which provides centralized observability and controls across all tool calls) are coming soon.
According to Mitch Ashley, VP and practice lead for software lifecycle engineering at The Futurum Group, “Tool wiring has become the operational bottleneck for enterprise agent deployment, and the integration layer is now control plane territory. Foundry Toolboxes position Microsoft to govern that layer regardless of which runtime executes the agent.”
Ashley continues, “The strategic value rests on the Discover and Govern pillars, still on the roadmap. Without centralized registries and observability across tool calls, enterprises retain credential sprawl and policy gaps that already constrain agent autonomy. Procurement should weigh Toolboxes against the governance roadmap, because preview tooling alone leaves those gaps in place.”
Not Locked to Foundry
One concern teams often raise with Microsoft-native tooling is vendor lock-in. Here, the answer is fairly clear. Toolboxes are created and governed in Foundry, but any agent runtime that supports MCP can consume them. That includes agents built with Microsoft Agent Framework, LangGraph, GitHub Copilot, Claude Code, or custom code.
You can manage tools centrally in Foundry and still use them across your existing agent infrastructure.
Getting Started
Getting a Toolbox up and running takes a few steps. You create an AIProjectClient, define your toolbox with the tools and authentication it needs, grab the unified MCP endpoint that Foundry generates, and attach it to your agent. Versioning is built in — you can promote a tested version to production, share the endpoint broadly, and continue iterating without breaking downstream agents.
Microsoft has published sample code for Microsoft Agent Framework, LangGraph, and Copilot SDK, along with an AZD CLI quickstart and support in the Foundry Toolkit for VS Code.
The Bigger Picture
Toolboxes reflect something the industry is starting to accept: the AI agent problem isn’t just about models. The integration and infrastructure layer matters just as much. Right now, tool wiring is often the bottleneck — not model capability.
If Toolboxes deliver on the governance and discoverability features still on the roadmap, this could be a meaningful step toward making enterprise agent development more reliable and repeatable. The public preview is a good place to test that assumption.
Documentation is available at Microsoft Learn, and the Foundry Portal is open for exploration at ai.azure.com.