What MCP Is and Is Not

All of Part VIII assumed you write the tools. This part is about what happens when someone else does. The first thing worth establishing is that the Model Context Protocol solves a distribution problem rather than a capability one.

Nothing MCP does is impossible without it. You could always write the function.

The problem it solves

Before a protocol, every agent client that wants to reach every system needs a bespoke integration. Three clients and four systems is twelve integrations, each written and maintained by someone.

   WITHOUT A PROTOCOL              WITH ONE

   client ─┬─▶ Jira                client ─┐
           ├─▶ Slack                       │      ┌─▶ Jira
           ├─▶ CRM                client ──┼─MCP──┼─▶ Slack
           └─▶ warehouse                   │      ├─▶ CRM
   client ─┬─▶ Jira                client ─┘      └─▶ warehouse
           ├─▶ Slack
           ⋮                       M + N integrations
   M × N integrations

That is an old shape with a good track record. It is the same trade the Language Server Protocol made for editors against languages, and ODBC made for applications against databases. In both cases the protocol was unexciting, the adoption argument was economic rather than technical, and the win was that the integration gets written once by the party that understands the system.

The carrier that ships Meridian's freight can publish one server. Every agent at every customer reaches it without the carrier knowing any of them exist. Meridian was never going to write that integration well, and the carrier was never going to write an integration per customer.

The problem people think it solves

Four misreadings, in rough order of how expensive they are.

"MCP makes my agent better at using tools." It does not. The model receives a name, a description, and a JSON Schema, identical whether that tool arrived over a protocol or was defined inline in your source file. The protocol terminates at your client; nothing about it reaches the model. Every chapter of Part VIII still applies in full, and MCP performs none of it for you. A badly described tool is badly described over any transport.

"MCP is a security boundary." It is a transport with an authentication story, which is a different thing from an authorization model for your business rules. The requester rule, the amount ceilings, the read/write split are all still yours, and some of them now sit on the far side of a network boundary operated by someone else.

"Adding servers adds capability." The previous chapter measured what it actually adds: 200–500 tokens per definition, and selection accuracy degrading past thirty to fifty tools. Capability arrives, and so does a bill that is invisible until you measure selection on your own ticket set.

"MCP replaces my API." It is a sibling of your API for a different consumer, which is the thesis of Part VIII restated at the protocol layer. An MCP server that wraps your REST endpoints one-to-one is the same anti-pattern in a new wrapper, and the ecosystem is full of them because generating one is a single command.

What is actually in the protocol

Three things a server offers, and three it can ask of the client. The split is worth keeping straight, because the two halves are negotiated in opposite directions. The distribution of what people use is the most interesting fact about them:

When someone says "we added MCP," they almost always mean tools. That is worth noticing, because resources and prompts are the two primitives that make MCP something other than a remote function call. A server that ships a well-designed extraction template, or exposes its documents as addressable read-only context the client can select from, is doing something your HTTP API genuinely cannot. Almost nobody does it.

The bottom three invert the usual direction, and 2026-07-28 changed both halves of how. There is no initialization handshake to declare them in any more. Every request carries the client's capabilities inline in _meta, and a server needing one the client did not offer gets MissingRequiredClientCapability rather than a degraded answer. Nor does the server call the client. Multi round-trip requests replaced server-initiated sampling/createMessage and roots/list with an input_required result that the client satisfies by retrying the original request with the answer attached.

So "does this server support sampling" was always the wrong question, since it is a fact about your client. And now there is a further one: Roots and Sampling are deprecated, on a twelve-month window, in favour of passing directories as ordinary tool parameters and calling your provider's API directly. Build on them today and you are building on a scheduled removal.

Two of the three deserve a flag beyond that:

Sampling lets the server ask your client to run a model call. The design intent is sensible. A server author can add intelligence without holding API keys or paying for inference. The consequence is that a third party's server can cause your billing account to generate tokens, on a prompt you did not write. That is a trust decision, not a configuration one.

Elicitation lets the server request input from the user mid-call: a confirmation, a missing parameter. It is the protocol growing its own version of the approval gate, and the same caution applies: a confirmation prompt authored by a third party is text you are rendering to your user with your product's authority.

The 2026 spec got more boring, on purpose

The current revision, 2026-07-28, is worth reading as a direction rather than a feature list. The headline changes:

• Sessions are gone. The protocol core is stateless: no Mcp-Session-Id, and tools/list no longer varies per connection. A server needing cross-call state now mints an explicit handle and passes it back as an ordinary tool argument.
• Server-to-client requests use multi round-trip requests rather than requiring a permanently open bidirectional stream.
• Routing headers, Mcp-Method and Mcp-Name, so a gateway, rate limiter, or WAF can route and meter without parsing the JSON body.
• List results carry ttlMs and cacheScope, so clients can cache the catalogue instead of re-fetching it.
• Authorization hardening, and a formal extensions framework.

Every one of those makes MCP look more like ordinary HTTP infrastructure and less like a bespoke session protocol. That is the maturation signal, and it is good news operationally: your existing load balancer, cache, WAF, and rate limiter start working on it without special cases.

It also quietly blesses a pattern this book already argued for. "State lives in an explicit, server-issued handle passed as an ordinary argument" is the parameterized-tool discipline. The model carries an identifier it was given rather than a program it composed. The protocol converged on it from the other side.

What it costs you

The honest ledger, since the benefits are well advertised:

A network boundary inside your agent loop. Every MCP tool call is a hop with its own latency, timeout, and failure modes, inside a loop that already costs two requests per tool use. Your issue_credit equivalent now has a second way to return "unknown," which is the idempotency problem arriving through a new door.

A dependency that changes without your deploy. A server can add a tool, reword a description, or alter behaviour on its own schedule. Your selection accuracy is downstream of text you do not control and did not review.

Descriptions as an attack surface. In a multi-server catalogue, tool names and descriptions are how the model chooses, and a server that names and describes a tool aggressively can win calls that belong to another server. Prompt injection covers the mechanics; the point here is that installing a server is trusting its prose, not just its code.

Blast radius is the whole declared catalogue. A server you installed can define any tool it likes, and deferring a tool hides it from the model rather than from your threat model. Allowlists are the control; the protocol is not one.

Atlas, concretely

Meridian ends up on both sides of the protocol, and the asymmetry is the useful part.

Consuming: the freight carrier's tracking server. Meridian would never have written that integration well. It is the carrier's domain, the carrier's schema, and the carrier's release cadence. This is MCP doing exactly the job in the diagram.

Publishing: Meridian exposes crm_account_risk_profile and erp_list_unpaid_invoices as a server, so the sales team's own agent can reach them. That agent is built by a different team, on a different stack, and the platform team will never see it. That is the framing the core path gave this part: you need to expose your tools to agents you did not write. The tool-design work from Part VIII is what makes that server worth consuming; the protocol is only the delivery.

Not using it: Atlas's own seven tools stay in-process function calls. Putting a protocol boundary between an agent and its own database adds a hop, a serialization, and a failure mode, and buys nothing. That is a whole chapter, two chapters from now.

References

• Model Context Protocol specification, 2026-07-28, the current revision's architecture and primitives.
• Specification changelog, what changed from the preceding revision, and why the date in the version matters.

Takeaways

• MCP solves a distribution problem, not a capability one. It turns M×N bespoke integrations into M+N, the same trade LSP made for editors and ODBC made for databases.
• The integration gets written once, by the party that understands the system. That is the entire value proposition and it is a real one.
• The protocol terminates at your client. The model sees the same name, description, and schema either way, so every chapter of Part VIII still applies, and MCP does none of it for you.
• It is a transport with an authentication story, not an authorization model for your business rules.
• Three server primitives: tools, resources, prompts. Almost everyone uses only tools. Resources and prompts are what would make a server something other than a remote function call.
• Sampling, elicitation, and roots are client capabilities, carried inline in _meta on every request since the initialization handshake was removed. Whether they are available is a fact about your client, not about the server. And Roots and Sampling are now deprecated, so new work should pass directories as tool parameters and call the provider API directly.
• Sampling inverts the direction: a third-party server can cause your account to generate tokens on a prompt you did not write. That is a trust decision.
• The 2026-07-28 revision removed sessions, moved server-to-client calls to multi round-trip requests, added routing headers and cacheable list results. Every change makes it look more like ordinary HTTP infrastructure.
• The stateless move blesses the parameterized-tool discipline: state travels as an explicit server-issued handle in an ordinary argument.
• Revisions differ meaningfully: SSE deprecated in 2025-03-26, OAuth 2.1 in 2025-06-18, sessions removed in 2026-07-28. Check which one each side implements before debugging.
• The costs: a network hop inside the agent loop, a dependency that changes without your deploy, descriptions you do not control, and a blast radius covering the whole declared catalogue.
• A server that wraps your REST API one-to-one is the Part VIII anti-pattern with a new transport.

Three things were deferred to make that argument cleanly. Next: Servers, Clients, Transports, where they turn out to be one thing wearing three names.