Skip to main content
Every agent needs the same tools. Configuring them once beats configuring them five times, and it is the only version you can actually govern.
MCP — the Model Context Protocol — is the open standard by which an AI agent discovers and calls tools: search an index, query a monitoring system, read a ticket, list files. An MCP server exposes one such capability; an agent that speaks the protocol can use any server without bespoke integration code. That is the piece that makes agents useful rather than merely conversational, and it creates a distribution problem the moment there is more than one agent.

​
The problem with per-agent tool config

The obvious way to give an agent a tool is to configure the MCP server in that agent’s own settings. With one agent this is fine. With several — a coding CLI, a background automation agent, an editor integration — the same server ends up configured several times. Every copy is a place to drift. One agent gets a new tool the others do not. A credential rotates and four configs update while the fifth does not. The version each agent pins diverges. And there is no single answer to a question that should be easy: what can our agents actually reach? This is the same shape as the model problem. The fix is the same shape too.

​
Register once, reach from everywhere

A tool plane is a gateway that sits between agents and MCP servers. A server is registered against the gateway once; every agent runtime dials the gateway. Adding a tool becomes one change that all agents inherit, rather than one change per agent. Two design choices make this pay off. Keep the gateway config-as-code and stateless. The gateway’s whole configuration should regenerate from version control on every deploy, holding no state worth backing up. Recovery becomes re-deploy rather than restore, and statelessness is what later allows several interchangeable instances. Keep the planes separate. Tool traffic and model traffic are different concerns, and it is reasonable — and simpler — for a tool gateway to handle only tools while inference continues to go straight to the model endpoint. Routing both through one component is a deliberate later choice, not a default. Consolidate what benefits from consolidation; do not consolidate for symmetry.

​
A shared plane is a shared blast radius

The consolidation has a cost that is easy to underrate: one gateway in front of every tool means one failure removes every tool from every agent at once. That is not hypothetical. A single-instance tool gateway going down takes an agent from “degraded” to “has no capabilities at all” instantly — and because the agent can still talk, the failure can look like the agent behaving strangely rather than infrastructure being down. The mitigation is the property the design already has. A stateless, config-as-code gateway can run as several identical instances behind a health check with no leader, no shared store, and no session affinity to preserve. The work is deploying them, not redesigning anything. Worth stating plainly: being architecturally ready to pool is not the same as being pooled. Until the additional instances are actually running, the single point of failure is still a single point of failure, and documentation should say so rather than describing the intended state in the present tense.

​
What this does not solve

A tool plane consolidates distribution, not authorization. Every agent reaching the same gateway does not mean every agent should reach every tool behind it. Scoping which agent may call which tool — and with whose credentials — is a separate problem, and putting a gateway in the path does not answer it. It does, however, give you one place to answer it.