I have spent a large part of my career on integration contracts. Payment messages crossing between systems that had never met. Partner APIs with sparse documentation, versioning bolted on too late, error codes that told you something broke without saying what. Most days the job was either building an API or consuming one, dressed in different clothes. So when a protocol for connecting models to tools started spreading through the industry, I read the specification the way I read any new partner's contract. And I recognised it immediately. Not the technology. The move. I had watched my own industry make it once before.
MCP is the oldest move in integration engineering applied to AI: replace pairwise glue with one contract. A model does not read your mind; it reads your contract – and the discipline of writing good contracts is one you already own.
- The N-times-M problem every integration veteran has lived through once already, and the four-message conversation that kills it.
- What a server can actually offer a model – three primitives, one handshake, two transports – in plain architect language.
- Why bespoke function calling lost, what makes a tool boring in the best sense, and the one security problem the protocol cannot solve for you.
The Model Context Protocol gets explained two ways, and both fail the working engineer. The hype version calls it a revolution and moves on. The reference version drops you into message schemas with no sense of why any of it exists. This piece takes the third road: MCP read as what it actually is – an API standard, with a lineage, a wire format, a handshake, and a set of design obligations that will feel almost nostalgically familiar if you have ever shipped an integration for a living.
The Problem Every Integration Engineer Recognises
Before the card networks settled on shared message standards, every connection in payments was its own project. A bank talking to a processor, a processor talking to a merchant platform: each pair negotiated its own formats, its own field meanings, its own error behaviour, and then certified the whole thing by hand. The cost of every new partner was a fresh integration, and the ecosystem's total effort grew with every pair – the dreaded N times M. The fix was not a better integration. It was a shared contract: one message standard the whole industry could certify against once, and reach everyone. ISO 8583 carried card payments on exactly that bargain for decades.
Now replay the early tool-calling era of AI with that lens. Every model provider had its own function-calling format. Every tool needed bespoke glue for every model it wanted to serve. Change providers, rewrite the glue; add a tool, wire it into every host by hand. N models times M tools, every link hand-made and hand-maintained. Anyone who lived through pre-standard payments felt the déjà vu, and could also predict the ending, because there is only one: somebody writes down a shared contract, and the pairwise glue dies.
That is what MCP is. Anthropic open-sourced it in late 2024, and within a year the ecosystem – including the rival labs – had converged on it. Write a tool server once, and any compliant host can use it. Build a host once, and every server on earth is a plug-in. N times M becomes N plus M. The revolution, as usual, is a well-written contract.
What Actually Happens on the Wire
Three parties, familiar roles. The host is the AI application – the chat app, the IDE, the agent runtime. The server is the thing with capabilities to offer – your database, your ticketing system, your payment platform's sandbox. Between them sits the client, a connector the host runs, one per server, holding the conversation. If you have ever drawn a box labelled adapter or gateway on a whiteboard, you have already designed this diagram.
The step that deserves your attention is the second one. Discovery happens at runtime. The host does not ship with your tool's schema baked in; it asks, every session, and the server answers with its current contract. Integration engineers will recognise what that buys: the consumer and the provider can evolve separately, version skew becomes a negotiation instead of an outage, and adding a capability does not require touching every consumer. The things we bolted onto APIs late and painfully – discoverability, capability negotiation – are the protocol's opening move.
Three Things a Server Can Offer
A server's whole vocabulary is three primitives, and the distinction between them is really a distinction about who decides.
Tools
Actions the model may invoke: run the query, file the ticket, issue the refund. Each is a name, a description, and a JSON Schema for its inputs. The description is documentation the model actually reads.
Resources
Data the server can hand over for context: files, records, tables. The application chooses what enters the window; the model does not go fishing on its own.
Prompts
Reusable templates a person explicitly picks – slash-commands with a contract. Intent stays authored by the human, not inferred by the machine.
The contract runs both ways: a server can also ask the host's model for a completion – the protocol calls it sampling – with the human still holding the keys. Even the reverse direction arrives permission-first.
Notice what this taxonomy quietly encodes. Tools, resources, and prompts are not three data formats; they are three trust boundaries – model-controlled, application-controlled, human-controlled. The protocol's authors baked the question of authority into its grammar, which is exactly where an integration engineer would want it: in the contract, not in the hope.
Why Bespoke Function Calling Lost
Function calling itself did not lose – MCP still delivers a tool call to the model in the end. What lost was the bespoke contract: every provider's private format, every integration hand-rolled. It lost for the same reason pairwise payment links lost, and the economics are worth stating plainly, because they explain the speed of the flip.
Under bespoke glue, the cost of the ecosystem grows with every pair, and every tool author must bet on which model provider to support first. Under a shared contract, a tool author writes one server and inherits every host, present and future; a host author implements one client and inherits every tool. The incentive to defect is nearly zero and the incentive to join compounds daily. Standards with that shape do not win slowly. In payments the convergence took decades because the incumbents moved at the speed of banks. In AI it took about a year – the fastest standardisation I have watched an industry perform. The lesson transferred; only the tempo changed.
There is a strategic reading too, the one Chapter 4's stack hints at: models themselves are converging in capability, so the durable value migrates to the layers that connect them to the world. Owning good servers – clean, certified access to your systems – is a longer-lived asset than any prompt. Contracts outlive the parties that sign them. Integration engineers have always known this; now it is AI strategy.
A Good Server Is Just a Good API
I have argued before that if developers are your users, their frustration is your API's failure rate. The reframe survives contact with AI intact, and gets sharper: if a model is your user, its confusion is your contract's failure rate – and unlike a human developer, the model will not read your mind, ask on Slack, or lose interest halfway. It reads exactly what you gave it: the name, the description, the schema, the error. Every weakness in the contract becomes behaviour, immediately, in production.
Which means the disciplines you already own transfer line for line:
The route's Stage 03 sets the bar in one word: boring. Small, sharp tools that do one thing, validate their inputs, and can be tested on their own. A tool named do_stuff with a paragraph of vague description is the sparse-documentation partner API of this era, and the model integrating it will flounder exactly the way I once did – except at machine speed, in front of your customers. Write the contract you always wished your worst integration partner had written.
The One Problem the Protocol Cannot Solve
A clean contract does not answer the oldest question in security: on whose authority? An MCP server acts with your credentials on the model's word, and the model's word can be shaped by whatever text it last read – a poisoned document, a malicious tool result, a clever email. Security people call this the confused deputy, and it is the heart of Chapter 17's argument and of the Instagram case: capability is not authority, and a system that cannot tell them apart will eventually act on the wrong one.
The protocol gives you the hooks – scoped permissions, human-in-the-loop gates, structured boundaries between what is offered and what is invoked – but hooks are not policy. Payments learned this lesson so thoroughly it split the act in two: authorization is not clearing, and nothing irreversible happens on the first message. Bring that instinct with you. Treat tool results as untrusted input, gate anything that cannot be undone, and let the model propose while something with actual authority disposes.
Give It Hands, Carefully
Stage 03 of the Route is called Give It Hands, and it is the stage where AI stops being a conversation and starts being a system – with everything that word carries. What strikes me most, reading the protocol with two decades of integration scars, is how little of it is new. The handshake, the catalogue, the schemas, the idempotency, the least privilege: this is the accumulated wisdom of every integration that ever failed at 2 a.m., written down for a new kind of consumer. The engineers who spent careers making systems talk safely to each other are not late to this. They wrote the curriculum. The only new student in the room is the model.
Hands come before autonomy. The stage after this one is where the loop closes: Chapter 5 · What Agents Actually Need covers what production demands once the model can act. Or step back onto the Route at Stage 03 – and when you are ready to practice, the cookbook is the doing half.