MCP is plumbing, not intelligence

This is a technical piece, written for those of you who build or are about to buy agent solutions.

In short: MCP is an integration protocol, not an agent platform. The July revision solved much of what was the protocol's responsibility, such as sessions, routing and authorization, but not what a protocol can never solve: context cost, unnecessary model round-trips and large volumes of data passing through the model. Use MCP as the outer boundary, and build the core yourself.

MCP has been blamed for a lot it was never meant to solve. I've been sceptical of the Model Context Protocol myself since I first started using it. Not because the idea is bad, but because for a long time the protocol made a necessary task more complicated than it needed to be.

Then came the revision on 28 July 2026, which David Soria Parra, one of MCP's lead maintainers, calls the most important since remote MCP was launched. It cleaned up much of what I had been sceptical about, but not everything. My background is twofold: I'm building Capassa, a fintech platform with its own AI agents, and I also help clients with network infrastructure in the healthcare sector. That gives me two quite different perspectives on the same protocol, and both have made me focused on what works in production, not just in a demo.

MCP is plumbing

MCP doesn't make a language model smarter. It's a protocol based on JSON-RPC that standardises how applications discover and use tools, resources and prompt templates from external services. It makes integrations more predictable and gives organisations a natural place to gather access control, policy and logging, provided they actually build the controls around the protocol. That's valuable, in the same way HTTP and OAuth are valuable. But it's plumbing. Planning, memory, error handling and orchestration, much of what makes an agent work, don't come from using MCP. They have to be built into the surrounding system.

Much of the disappointment I've heard about MCP comes from people expecting intelligence from a pipe. That's why it's useful to separate what is the protocol's responsibility from what is yours: The protocol can be fixed, but agent design is your responsibility. My position in one sentence: MCP is right as the outer boundary, but rarely the best starting point for the inner core of an agent you control yourself.

What the protocol could fix, and what July actually fixed

Some of my objections were about the protocol itself. Sessions: Earlier versions required an initialize handshake, and in Streamable HTTP the server could assign an Mcp-Session-Id that the client had to send with later requests (the November 2025 specification). It wasn't mandatory, but when it held state, you had to account for routing and storage across server instances, and that's more complexity than I want in a system that needs to scale horizontally. Authorization: OAuth support was an important step, but getting client registration, identity and access control to work well together was demanding. Dynamic Client Registration (DCR) isn't a security flaw in itself, since registration doesn't automatically grant access, but it's a component that has to be handled correctly, and in regulated environments such details are absolutely critical.

The July revision made the MCP core stateless and removed several of the practical obstacles to operating at larger scale. These are the changes I think matter most:

Two details are particularly interesting. One is the recommendation of explicit handles: If a service needs to preserve state between calls, it can return an identifier that the agent sends along next time. That's better than state hidden in the transport, both for debugging and for the agent's ability to keep track of the workflow. The other is that the four software development kits (SDKs) at the highest support level, Tier 1, for TypeScript, Python, Go and C#, supported the new version at launch. A specification is worth little if the tooling around it doesn't keep up. The details are in the release post and the changelog.

What a protocol can never solve

Other objections aren't about the protocol, and no revision solves them. Three challenges lie with whoever builds the agent.

The context cost doesn't go away. When an agent presents many tool definitions to the model at once, they take up space in the context window: Twenty servers with fifty tools each potentially means a thousand definitions, and that can cost tokens, time and precision. Caching reduces repeated catalogue lookups, but not necessarily the amount of tool information sent to the model. A large tool landscape still has to be curated, searched or loaded dynamically.

Unnecessary model round-trips are still expensive. MCP doesn't force every operation through a new model decision, and clients can make several calls programmatically. But if an agent lets the model plan every single sub-step in a thirty-step process, the solution quickly becomes slow, costly and error-prone. Many of those steps should be ordinary program logic.

The model is a poor channel for large volumes of data. For a set of accounts with 40,000 vouchers or a network topology with 3,000 nodes, it rarely makes sense to send raw data through the model. It needs relevant deviations, key figures and explanations, not every voucher or every configuration line. An agent can have access to the entire set of accounts, but the question is what happens to the data along the way: Should 40,000 vouchers go through the language model, or should code filter them first and give the model only the deviations? That can be solved with tools that filter on the server side, direct API calls or controlled code execution. The point isn't that MCP forbids such solutions, but that MCP doesn't replace them either. It's the same thinking as in AI can give a perfect answer. Based on the wrong numbers.: It isn't access to data that matters, but that the model gets the right information in the right context.

I'm not alone in this view. Anthropic describes exactly the same problem in "Code execution with MCP", where intermediate results stay in an execution environment instead of passing through the model, and in their own example token usage fell from 150,000 to 2,000. Cloudflare has arrived at the same thing under the name Code Mode. Anthropic is also honest about the cost: Code written by the agent has to run in a secure sandbox with resource limits and monitoring, and those are operating costs that direct tool calls avoid. I read the deprecation of Roots, Sampling and Logging as a signal that the maintainers want a clearer boundary between protocol and agent logic. That's a sensible direction. MCP doesn't need to be the whole agent platform to be useful.

If you're a buyer rather than a builder, the point is the same: The number of integrations an AI solution has says little about how reliable it is. Don't ask how many systems it connects to, but what it does with the data on the way, and who controls it.

My position in practice

Use MCP when you need to expose functionality to clients and environments you don't control: Claude, Copilot, customers' own agents or other departments' systems, and when standardised tool discovery and a shared integration point provide real value. With a stateless protocol core and a more mature authorization model, MCP now fits far better behind existing gateway, WAF and identity infrastructure, even though security never comes free with the protocol.

Don't use MCP by default between your own agent and all your own services. Direct function calls, ordinary APIs and a thin orchestration layer will often be easier to operate and debug, and when data volumes require it, calculations should be done outside the model, with clear access boundaries and traceability.

That gives a simple division of labour: MCP on the outside, where other AI clients need access, and direct service calls on the inside, where code does the heavy data processing. MCP becomes the entrance to the capabilities, not the engine that drives them. If you're building new integrations, I would choose 2026-07-28 and plan migration of older implementations. Deprecated features have a minimum window of twelve months, but there's little reason to build new dependencies on mechanisms the protocol is moving away from.

Finally

My scepticism was justified, but it's smaller now. The July revision shows a project willing to make breaking changes to fix fundamental weaknesses, and that's a good sign. What remains isn't necessarily a flaw in MCP. It's the limits of what an integration protocol should do. If you understand those limits, MCP can become an important part of a robust agent architecture. If you expect intelligence from a pipe, you'll be disappointed again.