Govern Tools Once With Foundry Toolbox and Reuse Everywhere

Left alone, every agent team re-implements the same tools, scatters credentials across repos, and loses governance visibility. Microsoft Foundry Toolbox answers with a curated versioned tool set behind a single MCP-compatible endpoint. Credentials live in Foundry connections, never in agent code. Every agent consumes tools through one endpoint with zero per-team tool code.

I run Daily AI World and standardize agent tooling at SaaSNext. Direct answer:

• One endpoint for all teams: agents call versioned tools without owning implementations
• Blue-green tool versions: test on a version-specific endpoint, promote to default, consumers update with zero code changes
• RAI guardrails at the toolbox layer, independent of model-level content filters

Here is the sprawl problem, the toolbox pattern, and the client code.

Tool sprawl is a governance incident in slow motion

Three teams need customer lookup. Team A writes a direct API client with a personal key. Team B wraps it in an MCP server with different schemas. Team C copies Team A and adds caching. A credential rotates and two agents break silently. Security asks who can see PII and nobody can answer completely. Multiply by twenty tools and the agent fleet runs on tribal knowledge.

The toolbox inverts ownership. A platform team curates tools, versions them, and attaches guardrails. Product teams consume. When a tool changes, the version-specific endpoint carries the new behavior for testing while default serves stable. Promotion flips every consumer at once. My eval-gate pipeline that blocks regressions plugs at promotion time: new tool versions pass golden evals before becoming default.

Credentials deserve emphasis. Foundry connections hold secrets server-side. Agent code references connection names. Key rotation happens once centrally instead of across N repos. My Stripe restricted-key architecture is the same principle at payment scope: least-privilege keys, central ownership, blast radius by design.

Production war story 1: the rotated key that broke three agents

In our fleet each team held its own CRM key. Security rotated the CRM credential on a Tuesday morning. By lunch two support agents and one sales agent failed with auth errors. Each team debugged independently. Total downtime overlapped 6 hours because nobody knew the other two were broken the same way. Postmortem counted 11 credential copies across repos, chat logs, and CI secrets.

We moved CRM access behind one versioned tool with the secret in a managed connection. Next rotation took 4 minutes with zero agent changes. Lesson: credentials multiply with teams while ownership stays flat. Centralize before the rotation, not after the outage. The Foundry hosted-agent split between compute and data completes the picture: connections live beside capability hosts in your tenant boundary.

Production war story 2: the schema change that broke quoting

When our pricing tool added a required region field, four agents kept calling the old schema. Two failed loudly. Two worse ones guessed a region and quoted wrong prices for 3 days. Revenue impact stayed small only because a human caught a Portuguese quote with US tax math. Root cause was versioning by hope: latest always, no pinned contract.

Blue-green tool versions fix exactly this. New schema ships as v3 on its endpoint. Teams test, update calls, then v3 promotes to default. Consumers pinning v2 keep working until they migrate deliberately. Pydantic v2.8 added friction here as usual: nested arg schemas dropped the new field until extra="allow" restored it, so pin client validation open and fail loudly on unknown fields. My Postgres HypoPG discipline of simulating before committing is the habit: prove against the versioned endpoint first.

Runnable production code: version-pinned toolbox client

Pin versions, approve writes, log everything.

File 1: config.py

from pydantic_settings import BaseSettings
from pydantic import Field

class Settings(BaseSettings):
    toolbox_url: str = Field(alias="TOOLBOX_URL")
    toolbox_version: str = Field(default="v2", alias="TOOLBOX_VERSION")
    allow_promote_auto: bool = Field(default=False, alias="TOOLBOX_AUTO_PROMOTE")
    write_approval: bool = True

    class Config:
        extra = "allow"

settings = Settings()

File 2: client.py

import logging
from config import settings

log = logging.getLogger("toolbox")

READ_TOOLS = {"customer_lookup", "order_status", "docs_search"}
WRITE_TOOLS = {"create_ticket", "issue_refund", "update_crm"}

def endpoint(tool: str, version: str = None) -> str:
    v = version or settings.toolbox_version
    return f"{settings.toolbox_url}/tools/{tool}/{v}"

def call_tool(tool: str, args: dict, transport) -> dict:
    if tool in WRITE_TOOLS and settings.write_approval:
        return {"action": "ask_human", "proposal": {"tool": tool, "args": args}}
    url = endpoint(tool)
    log.info("tool call %s %s", tool, url)
    return transport.post(url, json=args)

def promote_candidate(tool: str, candidate: str, evals_passed: bool) -> str:
    # Blue-green: candidate endpoint first, default only after evals
    if not evals_passed:
        return f"held {tool} {candidate}: evals red"
    if not settings.allow_promote_auto:
        return f"ready {tool} {candidate}: needs human promote"
    return f"promoted {tool} {candidate} to default"

if __name__ == "__main__":
    print(endpoint("customer_lookup"))
    print(promote_candidate("customer_lookup", "v3", True))

File 3: requirements.txt

httpx==0.28.0
pydantic==2.8.0
pydantic-settings==2.5.0
mcp==1.8.0

Run it:

uv pip install -r requirements.txt
python client.py

Step 1: register tools once with pinned versions. Step 2: point agents at the single endpoint with connection-based auth. Step 3: gate promotions on evals. For fleet-wide connector discipline, mirror the governance pattern for hundreds of tools.

Migration path from sprawl to toolbox in 4 weeks

Week 1 inventories everything. Scan repos for direct API clients, MCP servers, and secret copies. Our first inventory found 23 customer-data access paths owned by 5 teams, with 11 live credential copies. Rank tools by blast radius times call volume. CRM lookup, refunds, and search go first. Week 2 wraps the top 3 tools behind versioned endpoints with connection auth while leaving old paths live. Week 3 moves one pilot team per tool, measures latency delta and error parity, and backfills eval cases from production traffic. Week 4 flips remaining teams, deprecates direct paths with sunset headers, and deletes scattered secrets. Total platform effort ran about 3 engineer-weeks for our 6 highest-risk tools. Credential-related incidents fell from 3 per quarter to zero in the two quarters since.

Latency budgeting keeps the migration honest. The extra hop adds 8 to 15ms p50 per call in our measurements, negligible against 900ms model turns but visible on hot autocomplete paths. Two tools stayed direct with platform-reviewed exceptions: typeahead search and token streaming guards. Everything else moved behind versions. Track cost per tool call monthly. Centralization reveals the true bill for the first time, usually 20% higher than summed guesses because shadow usage surfaces. That visibility pays for the platform work within one quarter through duplicate-call elimination alone.

When NOT to centralize a tool

Do not toolbox experimental spikes. Let teams prototype directly, then graduate proven tools into the curated set. Centralizing too early slows discovery.

Do not hide latency behind versioning. A versioned endpoint adds a hop. Measure p95 per tool and keep hot paths local when milliseconds matter.

Do not skip the RAI review at promotion. Model filters and toolbox policies differ. A tool passing evals can still need disclosure rules or PII redaction before default traffic.

Verdict for September 2026 platform teams

Curate once, version everything, hold secrets centrally, promote on evals. Tool sprawl ends where platform ownership begins.

By Deepak Bagada, Founder & Editor-in-Chief at Daily AI World. I run shared agent tooling at SaaSNext and promote on green evals only. More at https://deepakbagada.in.