The Model Context Protocol is an open standard that lets an AI agent discover what tools a system offers and call them, using one shared interface instead of a custom integration per agent. That’s the whole idea. It is genuinely useful and genuinely small.
Most of the confusion around MCP comes from how much weight that small idea has to carry. The protocol covers discovery and invocation cleanly, and then stops. Everything else you’ll need to run an agent against your real systems, MCP leaves to you on purpose. This post covers both halves: what the protocol actually is, and the four things it deliberately doesn’t solve.
If you run a platform team and you’ve been nodding along in agent meetings without a crisp definition, this is the one to read.
Why the protocol exists at all
For as long as anyone reading this has been writing software, the thing on the other end of an API was a person, or code a person wrote. A developer read your documentation, worked out which endpoints to call in which order, wrote the integration, and tested it. It was authored once, deliberately, by someone who understood what they meant.
An agent doesn’t work that way. The caller is now a model that decides at runtime that it needs your order data, and there is no developer in the loop to read your docs and wire it up first. The agent has to find out what you can do and how to call it on its own, in the middle of a task it’s reasoning through.
Before MCP, you solved that with a tool wrapper per system per agent. You hand-wrote a function describing your order API to the model, injected credentials, hoped the model called it with sane arguments, then wrote it all again for the next system, and again for the next agent framework. None of it transferred and all of it rotted. MCP exists to collapse that into one contract any compliant agent can read.
The actual mechanics: three roles and a schema
Strip away the marketing and MCP is three roles and one good idea.
- The host is the AI application a user is actually talking to. It’s where the model runs and decides what to do next.
- The client lives inside the host and speaks the protocol. It connects out to servers, asks each what it offers, and makes the calls the model requests.
- The server is the part you build. It exposes real capabilities and answers two questions: what tools do I have, and run this one.
If you’ve built against a typed web API, the shape is familiar. Two parties agree on a contract and exchange structured messages, and neither needs to know the other’s internals. The one genuinely new thing is hiding in that word contract.
In MCP the contract is a machine-readable schema. The server doesn’t hand the agent prose documentation; it returns a list of tools, each with a name, a description, and typed input and output shapes the model parses. The agent reads that schema and decides what to call. That is the quiet center of the whole protocol: the agent reads your schema, not your docs, and it acts on exactly what the schema says, not on what you meant.
That single design choice is why MCP works, and it’s also where the discipline lives. A vague description or a loosely typed field isn’t a documentation cleanup you do later. It’s a live instruction to a model that will fill any gap in the contract with a confident guess.
The agent reads your schema, not your docs. It does exactly what the contract says, not what you meant.
What MCP does not do
Here’s the part the sales pitches hurry past. MCP standardizes how an agent discovers and invokes a tool. That is the boundary of what it covers. Four things you will care about the moment this is real are, by design, not the protocol’s job.
| Concern | What MCP says about it |
|---|---|
| Who the agent acts for | almost nothing — identity is yours to carry |
| Whether you can see what it did | nothing — observability is yours to build |
| Whether the tool stays the one you published | nothing — versioning is yours to enforce |
| Whether a destructive call gets gated | a risk hint at most — enforcement is yours |
This isn’t a flaw in the protocol. A standard that tried to mandate your auth model, your tracing stack, and your change-management process would be a standard nobody adopted. MCP drew its boundary on purpose and left the rest to the implementation, which is a polite way of saying it left the rest to you.
The trouble is that the demo doesn’t make any of this visible. A toy MCP server is one user, one static key, two read-only tools, running on your laptop. It works on the first try. Then the same server faces real traffic and every shortcut that made the demo easy turns into the thing keeping you up. The single key is now one key for everyone. The agent that helpfully called your tool forty times in a loop is now doing it on behalf of a customer who should never have seen what came back.
The four questions that decide whether it survives production
When real agents call real tools for real customers, four questions decide whether the thing holds up. None of them is answered by the spec, and you’ll meet all four whether or not you planned for them.
Who is the agent acting for? The agent isn’t a user with a session; it’s a process acting on behalf of someone, and that someone changes on every request. The same agent calling the same tool must act for a different customer each time and be unable to act for the wrong one. So identity can’t be a property of the server you deployed. It has to ride with each call and be enforced where the tool reaches your real systems.
Can you reconstruct what it did? An agent is a witness you can’t question. A person who does something wrong can be asked what they were thinking; an agent decided, retried, and composed calls on its own, fast and without narration, and by the time you notice the bad outcome the reasoning is gone. The trace is the only record left. This is why tracing on an open standard like OpenTelemetry matters more for agents than it ever did for human traffic: the span is the only thing you can read after the fact. If your tool calls disappear into a console with a week of retention, you’re debugging blind.
Will the tool stay the one you published? A demo’s tools change whenever you change your mind, which is fine when the only caller is you. It’s an incident when the caller is an agent that leaned on the contract being true. The shape an agent can call needs to be something you published on purpose and froze, not whatever your live config happens to look like this afternoon. Otherwise the agent discovers your change the hard way, in a loop, against a contract that no longer means what it did.
Can you gate the dangerous calls? Reading an order and cancelling one are not the same risk, and the protocol won’t tell the difference for you. You decide which operations an agent may even see, classify what’s read versus write versus destructive, and gate the destructive ones before they run rather than explaining them after.
So, honestly: should you care about MCP?
Yes, with clear eyes. The upside is real. Build a capability once as a server and any compliant agent can use it, this year and next, whatever model sits behind it. You stop writing a bespoke integration per agent and start publishing a capability once. That’s a genuine shift in how integration work compounds, and it’s worth adopting.
Just adopt it knowing the split. The protocol hands you discovery and invocation, cleanly, and that’s the whole of what it hands you. Everything that turns that into something you’d put in front of a customer is on your side of the line. The vendors are right that this is where a platform earns its keep. They’re just not always honest that the protocol itself is the small part and the governance is the hard part you’re actually buying.
For what it’s worth, that hard part is the reason Koodisi exists: existing REST services exposed as governed tools through a versioned OpenAPI snapshot, OpenTelemetry tracing on every tier including the free Community tier, and a caller’s identity carried into every downstream call instead of bolted on after the first leak. You can stand up a governed, tenant-scoped tool on the free tier and see what the production version of all this feels like. But that’s a choice for after you understand the protocol, which was the only thing this post set out to give you.
You can learn the Model Context Protocol in an afternoon. Deciding how you’ll answer those four questions is what takes longer, and it’s the decision that actually matters.