Microsoft-Foundry | The .NET Blog

Foundry Toolboxes: One Endpoint for All Your Agent Tools

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Here’s a problem that sounds boring until you’ve actually hit it: your organization is building multiple AI agents, each one needs tools, and every team is wiring those tools up from scratch. Same Web Search integration, same Azure AI Search config, same GitHub MCP server connection — just in a different repo, by a different team, with different credentials and no shared governance.

Microsoft Foundry just shipped Toolboxes in public preview, and it’s a direct answer to that problem.

What’s a Toolbox?

A Toolbox is a named, reusable bundle of tools that you define once in Foundry and expose through a single MCP-compatible endpoint. Any agent runtime that speaks MCP can consume it — you’re not locked to Foundry Agents.

The pitch is simple: build once, consume anywhere. Define the tools, configure auth centrally (OAuth passthrough, Entra managed identity), publish the endpoint. Every agent that needs those tools connects to the endpoint and gets them all.

No per-tool wiring. No per-agent credential management.

The four pillars (two of which ship today)

The Toolbox feature is organized around four ideas:

Pillar	Status	What it does
Discover	Coming soon	Find existing approved tools without hunting
Build	Available now	Curate tools into a named, reusable bundle
Consume	Available now	Single MCP endpoint exposes all tools
Govern	Coming soon	Centralized auth + observability across all tool calls

Today the focus is on Build and Consume. That’s enough to remove the most immediate friction.

Getting started in practice

The SDK is Python-first for now. You start by creating an AIProjectClient and then build a toolbox:

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

Then you create a toolbox version with the tools you want to bundle:

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Search public and internal docs, then respond to GitHub issues.",
 tools=[
 {"type": "web_search", "description": "Search approved public documentation"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Once published, Foundry gives you a unified endpoint:

https://zava.services.ai.azure.com/api/projects/<project>/toolbox/<toolbox-name>/mcp?api-version=v1

Point any MCP-compatible agent runtime at that URL and it discovers all the tools in the bundle dynamically. One connection. All tools.

Not locked to Foundry Agents

This is worth spelling out because it’s a common concern when Microsoft ships something under the Foundry brand.

Toolboxes are created and governed in Foundry, but the consumption surface is the open MCP protocol. That means you can use them from:

Custom agents built with Microsoft Agent Framework, LangGraph, or your own code
GitHub Copilot and other MCP-enabled IDEs
Any other runtime that speaks MCP

You’re not locked in. The toolbox is Foundry-homed (that’s where you manage it) but not Foundry-bound (you can consume it from anywhere).

Why it matters now

The multi-agent wave is hitting production. Teams are building 5, 10, 20 agents — and the tool-wiring problem compounds fast. Every new agent is a new surface for duplicated config, stale credentials, and inconsistent behavior.

Toolboxes don’t solve governance and discovery yet (those are “coming soon”), but the Build + Consume foundation is enough to start centralizing. Once the Govern pillar ships, you’ll have a proper observable, centrally-controlled tool layer for your entire agent fleet.

Wrapping up

This is early — public preview, Python SDK first, with Discover and Govern still coming. But the model is sound, and the MCP-native design means it works with the tools you’re already building on. Take a look at the official announcement to get started.

Where Should You Host Your AI Agents on Azure? A Practical Decision Guide

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

If you’re building AI agents with .NET right now, you’ve probably noticed something: there are a lot of ways to host them on Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — and they all sound reasonable until you actually need to pick one. Microsoft just published a comprehensive guide to Azure AI agent hosting that clears this up, and I want to break it down from a practical .NET developer perspective.

The six options at a glance

Here’s how I’d summarize the landscape:

Option	Best for	You manage
Container Apps	Full container control without K8s complexity	Observability, state, lifecycle
AKS	Enterprise compliance, multi-cluster, custom networking	Everything (that’s the point)
Azure Functions	Event-driven, short-running agent tasks	Not much — true serverless
App Service	Simple HTTP agents, predictable traffic	Deployment, scaling config
Foundry Agents	Code-optional agents via portal/SDK	Almost nothing
Foundry Hosted Agents	Custom framework agents with managed infra	Your agent code only

The first four are general-purpose compute — you can run agents on them, but they weren’t designed for it. The last two are agent-native: they understand conversations, tool calls, and agent lifecycles as first-class concepts.

Foundry Hosted Agents — the sweet spot for .NET agent developers

Here’s what caught my attention. Foundry Hosted Agents sit right in the middle: you get the flexibility of running your own code (Semantic Kernel, Agent Framework, LangGraph — whatever) but the platform handles infrastructure, observability, and conversation management.

The key piece is the Hosting Adapter — a thin abstraction layer that bridges your agent framework to the Foundry platform. For Microsoft Agent Framework, it looks like this:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

That’s your entire hosting story. The adapter handles protocol translation, streaming via server-sent events, conversation history, and OpenTelemetry tracing — all automatically. No custom middleware, no manual plumbing.

Deploying is genuinely simple

I’ve deployed agents to Container Apps before and it works, but you end up writing a lot of glue code for state management and observability. With Hosted Agents and azd, the deployment is:

# Install the AI agent extension
azd ext install azure.ai.agents

# Init from a template
azd ai agent init

# Build, push, deploy — done
azd up

That single azd up builds your container, pushes it to ACR, provisions the Foundry project, deploys model endpoints, and starts your agent. Five steps collapsed into one command.

Built-in conversation management

This is the part that saves the most time in production. Instead of building your own conversation state store, Hosted Agents handle it natively:

# Create a persistent conversation
conversation = openai_client.conversations.create()

# First turn
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Second turn — context is preserved
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

No Redis. No Cosmos DB session store. No custom middleware for message serialization. The platform just handles it.

My decision framework

After going through all six options, here’s my quick mental model:

Do you need zero infrastructure? → Foundry Agents (portal/SDK, no containers)
Do you have custom agent code but want managed hosting? → Foundry Hosted Agents
Do you need event-driven, short-lived agent tasks? → Azure Functions
Do you need maximum container control without K8s? → Container Apps
Do you need strict compliance and multi-cluster? → AKS
Do you have a simple HTTP agent with predictable traffic? → App Service

For most .NET developers building with Semantic Kernel or Microsoft Agent Framework, Hosted Agents is likely the right starting point. You get scale-to-zero, built-in OpenTelemetry, conversation management, and framework flexibility — without managing Kubernetes or wiring up your own observability stack.

Wrapping up

The agent hosting landscape on Azure is maturing fast. If you’re starting a new AI agent project today, I’d seriously consider Foundry Hosted Agents before reaching for Container Apps or AKS out of habit. The managed infrastructure saves real time, and the hosting adapter pattern lets you keep your framework choice.

Check out the full guide from Microsoft and the Foundry Samples repo for working examples.