Skip to main content

Toolboxes in Microsoft Foundry

Microsoft has just introduced Toolboxes in MS Foundry - a managed, versioned bundle of curated tools that any MCP‑compatible agent can consume through a single endpoint, removing per‑agent wiring, centralizing auth, and enabling safer rollouts

What is a Toolbox in MS Foundry
Toolboxes in MS Foundry lets you define a reusable set of tools once (APIs, MCP servers, connectors, skills, flows), configure authentication centrally, and expose them through a single MCP‑compatible endpoint that agents discover and call at runtime. This removes duplicated integration code and secret sprawl across agents. Read more on toolboxes here.


How do Toolboxes Work?
Toolboxes are a named, versioned collection of tools you manage inside Microsoft Foundry and expose through a single MCP‑compatible endpoint. Each toolbox groups tools by namespace; tools can be APIs, MCP servers, connectors, skills, or flows. At runtime an agent points to the toolbox endpoint, discovers available tools, and invokes them. Foundry handles credential injection, token refresh, and routing so agents don’t need per‑agent wiring or secret management.

Creating a Toolbox in MS Foundry

  1. Design the toolbox
    - Select tools that multiple agents will need (APIs, connectors, skills).
    - Define namespaces and naming conventions to avoid collisions and make discovery predictable.
  2. Configure authentication
    - Store credentials centrally in Foundry and map them to tools.
    - Define token lifecycles and refresh behavior so agents never hold long‑lived secrets.
  3. Publish a version
    - Create a sandbox version and run integration tests with a consuming agent.
    - Validate observability: logs, traces, and metrics must show which agent invoked which tool.
  4. Consume from agents
    - Point agent runtimes to the toolbox MCP endpoint.
    - Invoke tools by namespace and name; rely on Foundry for auth and routing.
  5. Promote and operate
    - Promote a tested version to default when ready.
    - Monitor usage and costs; map toolbox calls to cost centers and owners.

Creating a Toolbox from a DotNet project

using Azure.Identity;
using Azure.AI.Projects;

// Create Foundry project client
var projectEndpoint =
     "https://<your-foundry-account>.services.ai.azure.com/api/projects/<your-project>";
AIProjectClient projectClient =
    new(new Uri(projectEndpoint), new DefaultAzureCredential());
AgentToolboxes toolboxClient =
    projectClient.AgentAdministrationClient.GetAgentToolboxes();

ProjectsAgentTool webTool = ProjectsAgentTool.AsProjectTool(
    ResponseTool.CreateWebSearchTool());

ProjectsAgentTool mcpTool =
    ProjectsAgentTool.AsProjectTool(ResponseTool.CreateMcpTool(
        serverLabel: "myserver",
        serverUri: new Uri("https://your-mcp-server.example.com"),
        toolCallApprovalPolicy: new McpToolCallApprovalPolicy(
            GlobalMcpToolCallApprovalPolicy.NeverRequireApproval
        )
    ));

ToolboxVersion toolboxVersion =
    await toolboxClient.CreateToolboxVersionAsync(
        toolboxName: "my-toolbox",
        tools: [webTool, mcpTool],
        description: "Toolbox with web search and an MCP server"
    );

Console.WriteLine($"Created toolbox: {toolboxVersion.Name}, version: {toolboxVersion.Version}");

Note:
You can select one of the two endpoint options below based on your role:

  • Toolbox developer - {project_endpoint}/toolboxes/{toolbox_name}/versions/{version}/mcp?api-version=v1
  • Toolbox consumer - {project_endpoint}/toolboxes/{toolbox_name}/mcp?api-version=v1
The first version of a new toolbox is automatically promoted to default_version (v1). If you need to change the default later, see Endpoint patterns.
You can confirm that the toolbox loads the expected tools by using an MCP client SDK against the endpoint. You can Use the REST API tab to verify tool availability from .NET, or use the Python MCP client SDK. Read more here

Integrate and use a toolbox in an agent from a DotNet project
The following code snippet:
  • Creates the  Azure OpenAI and Toolbox MCP clients using DefaultAzureCredential, pointing to the model deployment and the toolbox MCP endpoint.
  • The Toolbox client automatically discovers available tools (tools/list) and invokes them (tools/call).
  • Starts a ResponsesServer and injects both clients into an AgentConfig so the agent can use the model and toolbox tools at runtime.
using Azure.AI.AgentServer.Responses;
using Azure.AI.AgentServer.Responses.Models;
using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Extensions.DependencyInjection;
using OpenAI.Chat;

// Azure OpenAI endpoint and model deployment
var openAiEndpoint = "https://<account>.services.ai.azure.com";
var deployment = "gpt-4o";  // supports all toolbox tool types

// Toolbox MCP endpoint (platform-injected at runtime via TOOLBOX_MCP_ENDPOINT)
var toolboxEndpoint =
    "https://<account>.services.ai.azure.com/api/projects/<project>/toolboxes/<toolbox-name>/versions/<version>/mcp?api-version=v1";

// Azure OpenAI client
var credential = new DefaultAzureCredential();
var openAIClient = new AzureOpenAIClient(new Uri(openAiEndpoint), credential);
var chatClient = openAIClient.GetChatClient(deployment);

// Toolbox MCP client — discovers tools via tools/list, calls them via tools/call
var toolboxClient = new ToolboxMcpClient(toolboxEndpoint, credential);

ResponsesServer.Run<ToolboxHandler>(configure: builder =>
{
    builder.Services.AddSingleton(new AgentConfig(chatClient, toolboxClient));
});

In future iterations, once you have another production-ready version of a toolbox, you can update the toolbox again pointing to the newer version and without the need to change code and agent at all. Read more on Managing toolbox versions.

Helpful documentation:

Labels:

Comments

Post a Comment

Popular posts from this blog

User Security Governance (Preview) feature in D365 FO

Let's take a first look at User security governance . It is the latest set of features in the D365F&O 10.0.43 update which provides useful tools to System administrators for role management, licenses auditing, enhanced audit trails and versioning, supported with some useful very useful reports around license usage, separation of duties violations etc. Key aspects of this feature include: Role Management: Improved tools for creating, modifying, and managing user roles. Audit Trails: Enhanced tracking of changes made to security settings, helping administrators monitor and review security configurations. Compliance: Tools to ensure that security settings comply with organizational policies and regulatory requirements. Feature management A new feature called (Preview) User security governance has been added to Feature management to control the overall functionality. Navigate to System administration > Security > Security governance to explore all the features. Security analy...
Post a Comment
Read more

Microsoft Dynamics 365 FSCM Licensing - New Multi-License Mapping on Menu Items

Licensing in enterprise systems has long been a game of mapping menu items to license types, ticking boxes, and hoping your role design didn’t trigger unexpected costs. But with the 2025 updates to Dynamics 365 Finance and Operations, Microsoft has flipped the script—ushering in a smarter, more flexible model that reflects how users actually work. Let’s break it down. In the legacy model, each menu item was tied to a single license type. For instance, if a user accessed MenuItemA that had a Finance license type on it, they needed a Finance license. If they accessed MenuItemB with SCM assigned on it, they needed SCM. Simple? Yes. But also rigid, prone to over-licensing, and blind to real-world role overlap. Example:  This model treated licensing like a static blueprint—ignoring the nuance of blended roles, attach licenses, and shared responsibilities across departments. Fast forward to 2025. Microsoft’s new licensing logic is object-level, dynamic, and context-aware. Now, a single m...
2 comments
Read more

Conditionally Hiding Menu Items in D365 FinOps Menus Without Using Feature Keys

In Microsoft Dynamics 365 Finance and Operations (D365 F&O), menu items are the links that can be clicked on to access forms, reports, classes, jobs, and queries. Feature keys are typically used to control the visibility of menu items based on user licenses. However, there are scenarios where you might want to hide menu items conditionally without relying on feature keys.  This can be accomplished by extending the 'SysMenuNavigationObjectFactory' class and modifying the checkAddSubMenu(...) method.  Suppose we want to hide the  Vendor payment journal menu item under Accounts payable > Payments > Vendor payment journal Steps 1. Create an extension of the SysMenuNavigationObjectFactory class [ ExtensionOf ( classStr (SysMenuNavigationObjectFactory))] internal final class SysMenuNavigationObjectFactory_PS_Extension { } 2. Create a Chain of Command (CoC) for the checkAddSubMenu method [ ExtensionOf ( classStr (SysMenuNavigationObjectFactory))] internal final...
Post a Comment
Read more