Foundry Toolbox.

Foundry Toolbox is a Microsoft Foundry resource that groups tool configurations for use by agents. A toolbox can be named and versioned, allowing a team to manage a set of tools as a distinct part of its agent environment. In supported setups, an agent can connect to the toolbox through an integration such as Model Context Protocol (MCP), a protocol for connecting applications with tools and context providers.

The toolbox is not an agent, an AI model, or an orchestration system. It makes configured tools available through a managed resource, but the application still determines how and when those tools are used. Developers must define the agent’s behavior, connect the right data and services, and decide how the application handles tool results, errors, and sensitive actions.

Without a shared configuration point, developers may define similar tool connections separately in multiple agent applications. A toolbox offers another approach: group relevant configurations in one resource, then connect supported agents to it. This can make common tool setups easier to review and maintain.

Depending on the project and its configuration, a toolbox may include hosted tools or connections to external tool services. The specific capabilities available can vary. Centralizing configuration does not make all tools identical: each may have its own permissions, data handling, reliability, and operational requirements.

A typical interaction can be understood as a short chain of responsibilities:

1. Configure the tools. A developer or project owner selects and configures the tools that the agent may use.
2. Create or update a toolbox version. The configuration is organized and made available through a named toolbox version.
3. Connect the agent. The agent application is set up to use the toolbox through a supported integration.
4. Decide whether to call a tool. The agent’s runtime or application logic determines whether a tool is appropriate for the user’s request.
5. Process the result. The application interprets the tool’s response and decides what to show the user or do next.

The toolbox handles the configured tool resource. The agent application remains responsible for choosing a tool and using its results appropriately. That division should be clear in the design, especially when an agent can take actions rather than only retrieve information.

Consider an agent that helps employees check equipment maintenance history. The team configures access to an approved maintenance-data service and makes that tool available to the agent through a toolbox. An employee asks when a particular machine was last serviced. The application can use the configured tool to retrieve the record and present a response.

If the agent can also update the maintenance record, the organization needs to decide whether the employee must confirm the change, whether a person must approve it, and which users are authorized to make it. The toolbox can organize access to the tool, but it does not establish those business rules or guarantee that a requested action is appropriate.

Treat a toolbox as part of the application’s security and operations design. A connected tool may receive user input, retrieve organizational data, or perform actions. Teams need to understand what information crosses each connection, which identity and permissions apply, and how the tool behaves when access is denied or a service is unavailable.

Versioning can help teams manage configuration changes, but a new version can change what an agent can access or how it behaves. A tool description or configuration change may affect the agent’s choice of tool. Test updates with representative requests and failure cases before relying on them in an operational workflow.

A toolbox is not, by itself, an approval mechanism. If a tool requires user confirmation or human review, the runtime and surrounding application must enforce that requirement. Likewise, centralizing tool configuration does not automatically provide complete monitoring, data-retention controls, or governance across external services.

Before making a toolbox part of an agent architecture, clarify the responsibilities and boundaries around it:

• Which agents need the configured tools, and should they share the same set?
• Who can create, update, test, and publish toolbox versions?
• What data can each tool receive, retrieve, or change?
• Which actions require confirmation, elevated permissions, or human approval?
• How will the application handle unavailable tools or unexpected results?
• What testing is required before a configuration change is used in production?

A toolbox is most useful when its shared configuration makes ownership and change management clearer. If a tool is unique to one agent or tightly bound to that application’s logic, a direct integration may be simpler to understand and operate.

Foundry Toolbox provides a way to organize and version tool configurations used by agents in Microsoft Foundry. It can support reuse and make tool setup a more visible part of an agent architecture. It does not replace the model, application logic, identity design, or operational processes surrounding an agent.

A well-designed implementation defines who owns the toolbox, how changes are reviewed, and how agents are tested when their available tools change. Those practices help ensure that shared configuration improves maintainability without obscuring how an agent accesses information or performs actions.