Why a Protocol
A hardcoded tool is a function in one repository. That is exactly the right shape until a second agent needs the same capability, at which point somebody copies the file and the copy starts drifting the same afternoon. Sundry has three internal systems the support agent depends on and two more agents on the roadmap; done by copying, that is nine integration surfaces and no owner for any of them.
A protocol changes what a tool is. It stops being a function you build into your binary and becomes a capability a team publishes once, which any agent discovers at connection time. The gain is real and it is narrow — discovery, one invocation shape, and ownership landing where the domain knowledge already lives. Everything else you were hoping it would fix, it does not fix.
What Hardcoding Costs at the Second Agent
Sundry's second agent works seller operations: chasing suspended listings, reconciling balances, answering the marketplace team's questions about disputed charges. It needs order lookups too, so the team does the obvious thing and copies the support agent's wrapper — 180 lines, including the part that parses delivery timestamps, which the order system returns in the originating warehouse's local time with no offset attached. The support team found and fixed that in March. The copy was taken in February.
The expensive part is the invisibility rather than the duplicated code. When the orders team reshapes the charges array, they tell the consumers they know about, and nobody maintains a list of the rest. The support agent gets updated; the ops agent starts reading the delivery charge as the item price, quotes the wrong figure to the marketplace team for six weeks, and the discrepancy surfaces in a seller's complaint rather than in a test. Two wrappers around one API is not twice the work — it is one system with a second, undeclared client.
Discovery Instead of Compilation
A protocol removes the build-time link. The agent connects to a server at start-up and asks what tools exist; the server answers with names, descriptions and argument schemas, and the agent registers whatever came back. Adding a capability becomes a deployment on the server side rather than a release on the agent side. When the orders team adds a tool for disputed charges, the ops agent has it the next time it connects, without a pull request in a repository that team has never opened.
That same property is the one that will bite you. A description edited upstream on Tuesday changes your agent's behaviour on Tuesday, with nothing in your repository to show for it, and "we did not deploy anything" stops being an alibi. The fix is cheap and has to be in place from the first connection: record the tool list you actually received with every run, keep it beside the trace, and diff it when a resolution number moves. Chapter 13 makes that part of versioning; here it is just the receipt that lets you attribute a change at all.
Ownership Moves to the Domain Team
The orders team knows which of forty endpoints answers a delivery question, what "order too old for carrier tracking" means, and why an order can have a seller and a fulfiller that differ. That knowledge is what a good tool description carries, and it has been sitting one team away from the person writing the descriptions. Publishing tools over a protocol moves the writing to where the knowledge is, and the schema discipline from Chapter 3 — one sentence on when this tool is the right one, arguments named for the domain, an enum instead of free text — becomes the orders team's job.
The handover is not free, because that team has never watched a model pick the wrong tool. They will write a description that is accurate and useless: "Returns order data." Accuracy is not the bar; selection is. So the transfer needs a written agreement about who reviews a description change and what evidence it needs before it ships, which is exactly what Topic 22 sets down for Sundry. A protocol relocates the work. It does not do it.
What a Protocol Does Not Solve
It does not decide granularity for you. A server that publishes forty CRUD tools has moved Chapter 3's tool-surface problem behind a transport and made it somebody else's. The model still chooses from a list it can only partly distinguish, still mis-selects at the rate a bad surface earns, and the list is now written by people you do not sit near. The team that publishes forty tools thinks it has been generous.
It does not make anyone's descriptions good, and it authorizes nothing. Discovery hands the agent text written by whoever runs the server, and the model reads that text as instruction rather than as data. Nothing in a protocol asserts that a tool is safe to call, that this caller is allowed to call it, or that the result is true. Authorization, ceilings and audit stay on your side of the boundary — Topic 20 puts them there on purpose, and Chapter 12 explains what happens to teams that assumed otherwise.
The Standard That Emerged
MCP is what most of the ecosystem converged on, and as of 2026 it is the interface a new tool integration is expected to speak. It standardizes four things: how a client and a server talk to each other, how the client discovers what is available, how a tool is invoked, and how a result or an error comes back. That is enough to make servers interchangeable between agents, which is the whole point of a standard and the reason a server written for one team's agent works in another's without negotiation.
What it leaves alone, it leaves alone on purpose: granularity, description quality, authorization, rate limits, cost accounting, and whether the server deserves to be connected at all. Adopting it for a single agent with four local tools buys a process boundary, a transport and a trust decision to solve a duplication problem that has not happened yet. Wait for the second consumer, or for the moment the tool's owning team is not your team. One of those two arrives on its own.
- Adopting a protocol for a single agent with four local tools — you buy a process boundary, a transport, a discovery step and a trust decision to solve a duplication problem you do not have, and the indirection pays for itself at the second consumer rather than the first.
- Assuming a protocol implies trust — discovery hands the agent descriptions written by whoever runs the server, the model reads them as instructions, and connecting is therefore a security decision wearing an integration decision's clothes (Chapter 12).
- Expecting the protocol to fix granularity — forty CRUD tools published over MCP are still forty CRUD tools, selection accuracy falls exactly as it did when they were local functions, and now the surface is owned by a team that has never seen a mis-selection.
- Treating server-side tool changes as invisible — a description edited upstream changes your agent's behaviour with no deploy on your side, and without the tool list recorded per run there is nothing to diff when resolution drops four points overnight.
- Introduce a protocol when a second consumer appears, or when the tool's owning team is not the agent's team — those two conditions are what make the plumbing cheaper than the duplication.
- Version the server's tool list and record which version each run used, so a behaviour change is attributable to a specific description edit instead of argued about in a retro.
- Keep the granularity conversation with the owning team and write down the outcome — four task-shaped tools or forty CRUD ones is a design decision the protocol will not make for you.
- Pin every third-party server and review it as you would any dependency, before the first connection rather than after the first incident (Topic 23).
Knowledge Check
Sundry's ops agent was built by copying the support agent's order-API wrapper. The orders team then reshapes the charges array. What is the real cost of the copy?
- The duplication is invisible, so the change reaches one consumer while the other quietly reports stale numbers
- The extra 180 lines of wrapper code sit in two repositories and make both of them measurably harder to build
- The order system now serves two clients instead of one, so its own latency budget has to absorb the doubled traffic
- The agent pays for the same tool schema twice on every turn, because both wrappers register their own definitions
What actually changes for the agent team when a capability moves from a compiled-in wrapper to a tool discovered over a protocol?
- A new capability becomes a server deployment rather than an agent release, and behaviour can change with no commit of yours
- Tool selection gets more accurate, because the model receives richer schema information than a local function can provide
- Per-call latency drops, because the protocol removes the serialization work a local wrapper had to do before each call
- Authorization moves to the server, because the team that owns the capability now decides who is allowed to call it
A team publishes its forty internal CRUD endpoints as forty MCP tools. Your agent's tool-selection accuracy drops. What does the protocol have to say about it?
- Nothing, since granularity is left entirely to the publishing team that ships it
- The protocol caps how many tools one server may publish, so a surface that large has to be split before it can connect
- Discovery groups related tools automatically, so the model sees four categories rather than forty individual entries
- A schema validation step rejects tool descriptions that are too vague, which keeps published surfaces usable by default
An agent has four tools, all local functions, and no second consumer yet. Adopting a protocol now would be premature for which reason?
- A process boundary, a transport and a trust decision are paid immediately, against a duplication problem that has not happened
- The standard is too young to build on, so an integration written today would need rewriting within a couple of releases
- The model handles protocol-published tools less reliably than local functions, so accuracy would fall on the same eval set
- Audit logging stops working across a protocol boundary, so every refund the agent issues becomes untraceable after the move
You got correct