Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
A toolbox is a logical container for tools and doesn't deploy its own networking resources. The networking configuration of the Microsoft Foundry project that hosts the toolbox governs all network access.
When your project runs inside a virtual network (VNet) with network isolation (private link), agents reach the toolbox MCP endpoint through the project's private endpoint. Each downstream tool's traffic flows differently depending on the tool type.
Tool connectivity depends on where the downstream service is hosted. Some tools communicate with Azure resources that support private endpoints, some invoke services that run through the project's delegated subnet, and others depend on Microsoft-managed services that currently require public or backbone connectivity. Review how each tool behaves before you add it to a toolbox in a network-isolated environment.
Network isolation support for tools in a toolbox
Important
Before you call tool endpoints outside Foundry through your virtual network, provision a valid capability host at the Foundry project level. Currently, provisioning a capability host only at the Foundry account level is insufficient. Without a project-level capability host, these calls fail with network connectivity errors, such as name or host unknown.
Network-isolated projects work best with tools that support private endpoints or VNet subnet integration. Review the support table before building a toolbox intended for regulated or highly secured environments.
The following table shows how each tool's traffic flows when your project uses network isolation. Some tools route through your VNet subnet or a private endpoint, some use public endpoints or the Microsoft backbone network, and some aren't supported in a network-isolated project.
| Tool | VNet support (traffic flow) |
|---|---|
| Model Context Protocol (MCP) | ✅ Supported (through your VNet subnet). |
| Azure AI Search | ✅ Supported (through private endpoint). |
| File search | ✅ Supported (through private endpoint). |
| OpenAPI | ✅ Supported (through your VNet subnet). |
| Agent-to-agent (A2A) | ✅ Supported (through your VNet subnet). |
| Web search | ✅ Supported. Relies on Microsoft-managed public endpoints. |
| Code interpreter | ✅ Supported (Microsoft backbone network). |
| Skills | ✅ Supported (network behavior depends on the tools used by the skill). |
| Fabric IQ | ⚠️ Partial. Fabric IQ connectivity is provided through MCP integration. Support depends on the specific Fabric item and networking configuration. See Restrict network access. |
| Work IQ | ❌ Not supported in network-isolated projects. |
| Browser automation | ❌ Not supported. |
| Tool search | N/A |
Tools that use your VNet subnet communicate through the delegated subnet associated with the Foundry project. These tools can access resources reachable from that subnet, subject to your network security rules.
For the authoritative, tool-by-tool support matrix, see Agent tools with network isolation. For the full list of tools and their SDK and tooling support, see Feature support.
File search vector stores
When you enable a virtual network (VNet) for your project, recreate any existing vector stores if you don't use bring-your-own (BYO) resources.
If you created a vector store while VNet was enabled, recreate it after disabling VNet to make public calls.
Set up a network-secured project
Set up network isolation at the project level, then create your toolbox in that project. Choose a Bicep or Terraform template based on your agent project type and whether your downstream tools run behind a VNet.
Configure a Basic agent project
A Basic agent project uses platform-managed data resources. To place it inside your own virtual network with private endpoints and no public egress, deploy the 11-private-network-basic-vnet template. To restrict who can call the endpoint while keeping public egress, use 10-private-network-basic.
For Terraform, use 11-private-network-basic-vnet for VNet injection or 10-private-network-basic for a private endpoint without VNet injection.
Configure a Standard agent project
A Standard agent project brings your own data resources (Azure Cosmos DB, Azure Storage, and Azure AI Search). For full isolation with no public egress and bring-your-own data resources, deploy the 15-private-network-standard-agent-setup template.
For Terraform, use 15a-private-network-standard-agent-setup to create the networking resources. Use 15b-private-network-standard-agent-setup-byovnet to integrate with an existing VNet and private DNS zones.
Configure tools behind a virtual network
For a Standard agent project that accesses private MCP servers, OpenAPI tools, Azure Functions, or A2A agents, use the tools-enabled templates:
- Bicep:
19-private-network-agent-tools. - Terraform:
19-private-network-agent-setup-with-tools.
These templates configure the networking infrastructure for private tools. Follow the sample instructions to deploy and connect the downstream tools.
For the full template catalog and what each one provisions, see the infrastructure setup README. For a step-by-step walkthrough of customizing the scaffolded infrastructure, see Set up private networking for Foundry Agent Service.
To provision account-level and project-level capability hosts, see Configure capability hosts.