DEV Community

Conor Dobbs
Conor Dobbs

Posted on • Originally published at tools.thesoundmethod.me

Is MCP Dead? When the Model Context Protocol Earns Its Complexity

#ai #llm #mcp #opensource

a post titled "mcp is dead" hit the front page of hacker news last week with 311 points and almost 300 comments. that is the kind of headline that makes you click and then makes you roll your eyes, because nothing in this space dies on a six-month timeline. so i read the argument, pulled the numbers, and checked what the people building these protocols are saying. the short version: mcp is not dead. the idea that you should wire every tool you own into an mcp server is the thing that is dying, and that distinction matters if you are deciding what to build this year.

what people are angry about

the model context protocol, for anyone who skipped the hype, is a standard anthropic shipped in november 2024 so language models can talk to external tools and data through one consistent interface. think of it as a common plug. the pitch was good. you write one server, any compatible model can use it.

the complaint is about what that plug costs you. every tool an mcp server exposes ships its full definition into the model's context window on connect. the name, the parameter schema, the response format, all of it. the quandri writeup that started the latest round measured it: four servers connected, 77 tools, and 21,077 tokens gone before the model reads a single word from you. that is 10.5% of a 200k context window spent on definitions you mostly will not call. the linear server alone ate around 12,807 tokens for 42 tools when the author only ever used two of them.

then there is speed. the same teardown clocked mcp calls at roughly 3x slower per call and 9.4x slower on the first call once you count server initialization. add the failure modes anyone who has run these knows by heart: a server that will not start, mid-session auth that expires, a tool that dies halfway through a task and takes the run down with it.

this is not a fringe gripe. in march, perplexity's cto denis yarats said at their ask 2026 event that the company is moving away from mcp internally toward plain apis and command-line tools, citing the same context-window waste and clunky auth. that got picked up everywhere because it is a real signal from a team running agents at scale, not a hot take.

the part the headline skips

here is what gets lost when "mcp is dead" goes viral. anthropic, the company that created mcp, published its own engineering post on the same problem, and their framing is the opposite of a funeral. they call mcp the de-facto standard with thousands of community servers, and then they show you how to stop it from burning your context.

their fix is code execution. instead of the model picking from a wall of tool definitions and passing every intermediate result back through itself, you present mcp servers as code apis the model writes against. it discovers tools by exploring a filesystem and loads only the definitions the current task needs. their worked example takes a job from 150,000 tokens down to 2,000 tokens. that is a 98.7% cut, and it comes from filtering data before it ever reaches the model rather than streaming a two-hour meeting transcript through the context twice.

so the protocol is not the problem. loading everything eagerly is the problem. mcp is growing up, not dying.

what i would reach for

i build comparison content and small tools for a living, and i run agents against my own stack all day, so this is a practical question for me and not a debate-club one. the rule i have landed on is boring and it holds up.

reach for a cli first. if a service has a decent command-line tool, the model already half-knows it from man pages and stack overflow, it costs zero tokens in definitions, and you get one interface that humans and agents share. reach for skills next when you have a multi-step workflow worth documenting, because the instructions load only when the task calls for them. reach for a plain api call when you need something specific and fast.

mcp earns its place in a narrower set of cases than the 2024 hype suggested, and those cases are real:

  • the service has no cli and lives entirely behind a web ui
  • your users are not developers and a terminal is a non-starter
  • you need server-side guardrails, like query validation that refuses a DROP TABLE against a shared production database before it ever runs
  • you need real bidirectional communication rather than request and response

that database case is the one i would not give up. a cli cannot enforce access control that lives on the server. an mcp server can. when the blast radius is a shared prod database, the protocol overhead buys you safety, and that is a fair trade.

why this matters if you are building

the lesson is not "pick a side." it is that the interface between a model and your tools is a design decision with a measurable cost, and most teams were treating it as a default. if 10 to 50 percent of your context is gone before the work starts, your agent is dumber and slower for no reason, and you are paying for it on every call.

so audit what you connect. count the tools you expose against the tools you call. if you are running mcp, look at whether code execution or progressive loading cuts your token bill the way anthropic's numbers suggest it can. if a cli already exists, ask whether you need the server at all. and if you are going to build an mcp server, build it for the cases where it wins, with the access control and the bidirectional bits that justify it, instead of wrapping a rest api you could have called directly.

that last point is where most of the pain comes from. people build mcp servers because mcp is the thing you are supposed to build, not because the use case needed one. a well-scoped server that does one job with real guardrails is worth keeping. a server that exists to check a box is the 12,807 tokens you will resent later.

mcp is not dead. the reflex to connect everything through it is. build the server when the job calls for it, and reach for the cheaper interface the rest of the time.

if you want the patterns for building mcp servers that earn their keep, the structure, the tool design, the guardrails, i collected them in the mcp server cookbook. and if you are weighing protocols and tools more broadly, i write these teardowns over at tools.thesoundmethod.me.

sources

Top comments (0)