MCP Isn't Dead. It Just Has a Different Job.

The argument that MCP is past its prime keeps surfacing in developer circles. It goes something like this: MCP adds context bloat, loads verbose tool definitions into every request, introduces latency, and gets in the way when you want a coding agent to move fast and precisely. For that specific use case, it is a reasonable critique.

But it is also a narrow one.

Where the criticism lands

The concerns about MCP in coding agent contexts are real and worth taking seriously.

A long coding session already puts pressure on the context window. A complex refactor can fill thousands of tokens before a single tool call happens. Adding dense tool schemas to every interaction compounds the problem. When a developer needs precise control over what an agent sees and does, and when latency between actions adds up over a multi-step task, MCP’s abstraction layer can start to feel like friction rather than infrastructure.

Latency matters too. A developer waiting on a chain of tool calls in the middle of active debugging has different patience than someone asking for a restaurant recommendation on their phone. When the interaction is long and the context is already expensive, every added step costs something real.

So the developers who raise these concerns are not wrong. MCP has tradeoffs. In contexts where context economy is paramount and where tools need to be hand-selected and narrow, those tradeoffs can tip against it.

The problem MCP was actually built for

But MCP was not designed only for coding agents. It was designed to answer an older and harder question: how does any application expose its capabilities to conversational interfaces without requiring a custom integration to be built and maintained for every possible host?

Before protocols like MCP, the answer was: one integration at a time. An AI platform wants to let users check their calendar? The AI company builds a calendar connector. Another platform wants the same thing? They build another one. The calendar provider now maintains integrations with a dozen different hosts, each with its own format, auth flow, and update cadence.

This is not a theoretical inefficiency. It is the current state of most software integrations, and it is expensive. Each integration is a contract between two parties that neither wants to break but both eventually change.

MCP proposes something different: build to one interface, expose your capabilities once, work anywhere that speaks the protocol. For application developers, that is a meaningful deal. For AI platforms, it is the difference between curating a fixed list of hardcoded integrations and supporting an open, extensible ecosystem.

The context overhead argument does not generalize

The most common technical criticism of MCP is that the tool schema adds too much to the context. This is worth examining carefully, because the conclusion depends almost entirely on what was already in the context when the tool definition arrived.

In a long coding session, context fills up fast. An involved refactor can accumulate a great deal before a single tool call is made. Tool schemas that arrive with every interaction, whether relevant or not, compound that pressure. In that environment, persistent overhead has a real cost.

Ordinary end-user requests are a different situation. A short, focused query does not approach the same context constraints as an extended coding session. The overhead that puts genuine pressure on a long agentic task may be a more acceptable tradeoff when a user is asking a single question that touches a small number of services.

This is not a defense of verbosity. Protocols should be as lean as they can be while still being useful. But a user may reasonably trade some overhead for the ability to take useful actions across connected apps in a single conversation. The cost-benefit calculation changes depending on the nature of the request. Treating the coding-agent scenario as the universal baseline inflates the cost and understates the benefit for everyone else.

What this actually enables for end users

The value of MCP for end users is not a technical property. It is a product property.

Consider what it looks like when conversational access to software actually works. A user asks their assistant to reschedule a meeting before the end of the day, check whether a flight is delayed, summarize what happened in a Slack thread while they were traveling, and draft a short reply to a client. Each of those actions involves a different service. Each service stores its data differently and exposes its functionality differently.

Without a standardized way for the assistant to discover and call those capabilities, the assistant either requires each application to have built a bespoke integration specifically for that platform, or it cannot help at all. The user is back to opening four different apps.

With a protocol like MCP, each connected service describes what it can do in a common format. The assistant discovers the available tools, calls the right one, uses the result, and moves on. The user asked a question and got the outcome they wanted. They did not need to know which service was involved or how the connection worked.

That gap between what users want to say and what software can hear is the core problem. MCP is a practical attempt to close it.

What open and standardized actually buys

There is a version of this future that works without MCP or anything like it. AI companies could build every integration in-house, negotiate every API deal, and maintain every connector themselves. Some of them are doing exactly that for their highest-priority integrations.

But that version scales poorly and concentrates capability in platforms that can afford the negotiation work. A small productivity app does not have the leverage to get its integration included in the next major AI platform release. A niche professional tool does not make the priority list. Users of those products get a lesser conversational experience or none at all.

The open-protocol version looks different. If any application can expose its capabilities through a standard interface, and if AI hosts adopt that standard, then the ecosystem grows from both ends simultaneously. The small app ships an MCP server. The AI assistant picks it up. The user gets access without anyone having to broker a deal.

Whether that plays out depends on adoption, on the quality of the spec, and on whether the major platforms treat it as a genuine open standard or as a compatibility gesture. Those are fair things to watch. The structural argument for open protocols in integration-heavy ecosystems is not new, though. It has worked before.

Richer than chat, not a replacement for everything

Plain chat is useful. But “tell me about this” and “do this for me” are different interactions, and most software is built around things worth doing.

The category of interaction MCP enables for ordinary users is not magic. It is closer to what a capable assistant provides: look something up, book something, check something, return the result, without requiring the user to navigate a different interface for each step. One conversation. Multiple services. A coherent outcome.

That is richer than a search box and less demanding than learning a new interface for every task. It is also not a replacement for dashboards, forms, visual editors, or any structured interface that does things a conversational layer cannot. MCP does not obsolete those. It adds a layer that did not reliably exist before: structured, discoverable, standardized access to application capabilities through natural language.

This pattern is probably part of how people interact with software in the future. Not all of it. Not a replacement for every other interface. But a real and useful mode that extends the reach of conversational AI beyond what plain text responses can do.

Shortcomings worth naming

None of this means MCP is without real problems.

Tooling is still maturing. Authentication and permission flows for MCP-connected systems are not as standardized as the protocol itself, which means the experience of connecting services can vary significantly from one implementation to the next. Security considerations around what tools can do and what data they can access require careful handling and are not solved by the spec alone.

Discovery is also an open problem. The value of an open protocol depends on being able to find and trust the implementations that exist. Without good directories, quality signals, or review mechanisms, the theoretical benefit of an open ecosystem can fail to materialize in practice.

These are genuine limitations. They are the work still to be done, not arguments against the pattern itself.

What the argument actually gets right

The “MCP is dead” argument is right about one thing: for coding agents doing long, context-heavy, tool-intensive work, MCP’s tradeoffs can tip against it. That is a real constraint and developers are reasonable to work around it when they need to.

It is not right that this conclusion generalizes. The end-user case is different in scale, in context cost, in the nature of what is being asked, and in the structural problem it is trying to solve. Writing off the whole protocol based on one edge of its application misses the more interesting argument.

Something like MCP is probably part of the future of software interaction. Not because it is technically elegant in every scenario, but because the problem it addresses is real: software is useful, people want access to it through the interfaces they already use, and building every connection from scratch is a poor way to get there.

That is a calm bet, not a grand claim. The protocol has real work left to do. So does everyone building on it.