Sundry's order system, policy library and carrier integration belong to other teams, have their own deploy cadence, and were never going to be rewritten into an agent's repository. Five topics on reaching them over a protocol instead: what a hardcoded wrapper costs at the second consumer, the client-server-discovery model MCP settled on, connecting without letting a dead server kill a ticket, turning forty internal endpoints into four task-shaped tools, and an honest accounting of what installing somebody else's server actually grants.
5 topics
Chapter 3 built tools as functions in the agent's own codebase, which is the right shape for the first agent and the wrong shape for the second. Sundry's order system is forty HTTP endpoints owned by a team of six who have their own roadmap; the policy library and the carrier integration belong to two more teams. None of them are moving into Vera's repository, and the wrapper she wrote around the order API is already being copied into a second agent by people she has not met.
A protocol changes what a tool is. Instead of a function you compile in, it becomes a capability a team publishes once and any agent discovers at runtime. MCP is the interface most of the ecosystem converged on: a client inside the agent process, a server in front of each capability, a discovery step that learns what is on offer before the first call, and three kinds of thing a server can publish — tools, resources and prompts — of which tools carry nearly all the real usage.
The last topic is the one to read twice. Installing somebody else's server grants three things at once: tool descriptions the model reads and obeys, code running with your process's permissions, and content flowing into your context from a source you do not control. That third grant is not exotic — Sundry meets it inside its own order payload, where get_order returns a product description written by a marketplace seller. Marking it at the server boundary is a design decision here. Chapter 12 is where it stops being theoretical.
What a protocol puts between the loop and the capabilities
Your process · where every enforceable control still lives
The loop — build context, call the model, branch on the stop reason
One dispatchervalidate · authorize · log
Local toolsthe ones that move money
One client per connectiondiscovery, then the tool list
the protocol — discovery at connect time, one invocation shape, and a tool list priced into every turn
Servers · one in front of each capability, none of them holding a loop