You built an agent with twelve tools. Another team built one with fifteen. A third integrated the same customer database as both of you, in a third incompatible way.
Nobody can reuse anything. Every agent re-implements every integration, every framework defines tools differently, and moving between frameworks means rewriting all of it.
This is an ordinary integration problem, and it has the ordinary answer: a standard interface. Two families of protocol emerged to provide one, and they solve genuinely different problems.
Two problems, not one
Agent-to-tool. How does an agent discover and call capabilities — a database, a file store, an internal API? The tool is passive: it exposes functions and returns results. It does not reason.
Agent-to-agent. How does one agent delegate work to another that has its own goals, planning and autonomy? The peer is active: it may decompose the task, take time, stream progress, or refuse.
The distinction matters because the second requires things the first does not — task lifecycles, progress updates, negotiation about capability, and long-running work.
Diagram, as text
- Agent leads to Database server (tool protocol)
- Agent leads to File server (tool protocol)
- Agent leads to Peer agent (agent protocol)
- Peer agent leads to Its own tools
The tool protocol pattern
A client-server model. Servers expose capabilities with machine-readable schemas; clients discover and invoke them.
Typically three kinds of capability:
- Tools — functions with side effects the agent may call.
- Resources — data the agent may read, addressed by URI.
- Prompts — reusable templates a server offers for common tasks.
The value is write once, use anywhere. A team wraps its internal system as a server, and every agent in the company can use it without bespoke integration. It converts an N×M integration problem into N + M.
This is the same argument as any interface standard, and the same benefit: the wrapper becomes the contract, and both sides evolve independently.
The agent protocol pattern
Peer-to-peer. An agent publishes a description of what it can do; other agents discover it, delegate tasks, receive streamed progress, and get results.
The extra machinery over a tool call is real:
- Capability advertisement — what this agent is for, so a peer can decide whether to delegate.
- Task lifecycle — submitted, working, needs-input, completed, failed. Delegated work is not a function call that returns; it is a job.
- Streaming updates — long tasks report progress.
- Cross-organisational identity — the peer may not be inside your trust boundary.
What this actually buys you
Reuse. One integration serves every agent, rather than each rebuilding it.
Framework portability. Tools defined against a standard survive a change of agent framework — which matters, because that ecosystem churns quickly.
Separation of ownership. The team owning a system owns its server and its schema. Agent teams consume it without needing to understand the internals — the same boundary argument as microservices.
Composition across organisations. An agent can use a capability published by a different company without a bespoke integration.
Design considerations
Server granularity. One server per system is usually right — a database server, a ticketing server. A server exposing forty unrelated tools recreates the tool-set problem inside a single integration.
Schemas are documentation. Everything from the tool-use lesson holds: descriptions determine whether the model chooses correctly. A protocol standardises the transport, not the quality of your descriptions.
Versioning. A server is an API with consumers you may not know about. Additive changes are safe; renaming a parameter or changing its meaning breaks agents silently, because the model simply starts failing rather than throwing a type error.
Discovery has a cost. Every advertised capability consumes context. Connecting an agent to fifteen servers with ten tools each gives it 150 definitions — vastly more than it can select from reliably. Filter capabilities per task rather than exposing everything.
Failure semantics. A remote server can be slow, down or wrong. Apply timeouts, circuit breakers and fallbacks exactly as with any network dependency.
When to adopt one
Reach for a protocol when several agents need the same integrations, when teams other than yours will build agents against your systems, or when you want portability across frameworks.
Skip it when you have one agent with a handful of tools that only it uses. Direct function calls are simpler, and a protocol adds a network hop, a server to run and a schema to maintain for no benefit.
The reasoning mirrors microservices: the value is organisational — reuse and ownership boundaries across teams — not technical. A single team building a single agent should just call functions.
Check your understanding
Common mistakes
Adopting a protocol for a single agent. Overhead with no reuse to justify it.
Connecting every available server. Context cost and degraded selection.
Assuming a standard interface implies safety. Authorisation, validation and least privilege remain yours.
Trusting server output. It enters the model's context and can carry injected instructions.
Breaking schemas without versioning. Consumers fail silently rather than loudly.
One server for everything. Recreates the oversized tool-set problem inside one integration.
Practice
Your company has 6 agents and 30 internal tools, currently wired with bespoke integrations. Assess whether adopting a tool protocol is worth it, and what the migration looks like.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Count the integrations you have and the ones a protocol would replace them with.
Show a strong answer
Count first. Bespoke wiring in the worst case is 6 × 30 = 180 integration points. A protocol replaces this with 6 clients plus 30 servers — 36 pieces, each implemented once. That ratio is the entire argument, and at this scale it is a strong one.
But check the real number. If in practice each agent uses only five tools, you have 30 integrations, not 180, and the protocol replaces 30 with 36. The arithmetic reverses, so measure the actual coupling rather than the theoretical maximum.
What tips it in favour regardless of the count:
- New tools become available to every agent automatically, which is where the compounding value is.
- One place to implement authentication, logging, rate limiting and validation, rather than thirty inconsistent versions.
- Third-party tools become usable without writing an adapter each time.
The migration:
- Wrap, do not rewrite. Put a protocol server in front of an existing tool's interface; the tool's implementation is untouched. This makes each step small and reversible.
- Start with the tools used by the most agents, since those retire the most bespoke integrations per unit of work.
- Run both paths during the transition. Agents can use the protocol for migrated tools and the old wiring for the rest — there is no flag day.
- Move the cross-cutting concerns into the protocol layer once most tools are through, which is where the operational payoff actually lands.
What I would not do: adopt a protocol for a single agent and a handful of tools. At that scale it is indirection with no ecosystem to benefit from, and the honest answer is a clean internal interface.
Design the trust boundary for an agent that calls tools hosted by other teams and, in one case, by an external vendor. What do you enforce at the boundary?
Write your own answer first, on paper or in a note. Then compare.
Show a hint
A tool server you do not own is an untrusted party in both directions.
Show a strong answer
Both directions are untrusted, and that is the part usually missed. You must not send it more than it needs, and you must not believe what it returns.
Outbound — what leaves:
- Minimise the payload. Send the arguments the tool needs, not the conversation context. A tool server receiving full context receives every customer record the agent has seen.
- Authenticate as your service and pass a scoped identity, so the remote side can authorise, and so an audit can attribute the call.
- Never forward credentials the tool could reuse elsewhere.
Inbound — what returns:
- Validate against the schema before anything reaches the model. A malformed or oversized response should fail at the boundary.
- Treat the content as untrusted text. A tool result enters the model's context, so a compromised or malicious tool server can attempt prompt injection through its return value. Mark it as data, and never let a tool result grant capability.
- Cap the size. A tool returning a megabyte destroys the context budget and the bill.
Around the call:
- Timeout, retry policy and circuit breaker, as for any external dependency.
- A cost and iteration budget if the remote side is itself an agent, because otherwise its loop spends your money.
- Log the full request and response, since debugging a cross-team failure without both sides is guesswork.
The vendor case specifically: treat it as a supply-chain dependency. Pin the version if the protocol allows, review what data flows to it against your data-processing obligations, and have a kill switch that disables that one tool without redeploying the agent.
Key takeaways
- Protocols solve an integration problem, turning N×M bespoke connections into N + M.
- Agent-to-tool protocols expose passive capabilities; agent-to-agent protocols delegate to peers with their own autonomy, needing task lifecycles and streaming.
- The real benefits are reuse, framework portability and ownership boundaries — an organisational argument, like microservices.
- A protocol is not a security model. Authorisation, validation, scoped credentials and confirmation for destructive actions remain your responsibility.
- Tool results enter the context, so a malicious server is an injection vector.
- Every advertised capability costs context and hurts selection — filter per task rather than exposing everything.
- Adopt when several agents or teams share integrations; skip it for one agent with a few tools.
Further reading
- Anthropic, "Model Context Protocol" specification (2024) — the tool protocol pattern.
- Andrew Birrell and Bruce Nelson, "Implementing Remote Procedure Calls" (ACM TOCS, 1984) — the ancestry, including what marshalling across a boundary costs.
- Sam Newman, Building Microservices, second edition (O'Reilly, 2021), chapter 4 — integration and the N-to-M problem.
- OWASP, Top 10 for Large Language Model Applications (2023) — insecure plugin design.
- Michael Nygard, Release It!, second edition (Pragmatic Bookshelf, 2018) — boundaries around dependencies you do not control.