MCP is dead? The case for letting agents just write code

What happened

A blog post from Quandri's engineering team titled bluntly "MCP is dead" hit 138 points on Hacker News this week, and the comments split exactly along the line you'd expect: people who ship agents nodding along, people who build MCP servers furiously typing rebuttals. The post's core claim isn't that the Model Context Protocol is technically broken — it's that for the actual work most teams are doing with agents, MCP is the wrong shape of solution.

Quandri's argument runs roughly like this. They tried to build an agent that integrates with a handful of internal services. The MCP path required spinning up servers, defining tool schemas, managing auth handoffs, and shipping all of that to Claude or GPT before the agent could do anything useful. The non-MCP path: write a Python script with `requests`, hand the agent a file describing the endpoints, let it execute the script. The second path was three days of work and 200 lines of code. The first path was a sprint, a deployment, and a permanent operational burden.

This lands at a moment when Anthropic itself has been quietly de-emphasizing MCP in favor of what it calls skills — markdown files describing capabilities, paired with bash and code execution. The skills pattern is, in effect, a concession: most agent work is better expressed as "here's a procedure, here's a script, go run it" than as "here's a remote tool server, negotiate a protocol with it."

Why it matters

The interesting part isn't whether MCP is technically alive. It's clearly alive — Claude Desktop, Cursor, Zed, and dozens of IDEs ship MCP integrations, and Anthropic continues to invest in the spec. The interesting part is that the default architecture for agent tooling is being renegotiated in public, and the renegotiation favors the boring approach.

Consider the context-window math. Each MCP tool you register injects its schema into the model's system prompt. A modestly equipped MCP server — say, 20 tools with reasonable documentation — easily consumes 8-12k tokens before the agent reads a single user message. Multiply that by five connected servers and you've burned a third of a 128k context window on tool descriptions the agent may never invoke. Token costs aside, that's a measurable hit to reasoning quality: longer system prompts demonstrably degrade instruction-following in long-horizon tasks, a pattern Anthropic's own internal benchmarks have flagged.

Then there's the security surface. Prompt-injection attacks on MCP servers are now a recurring item at security conferences. The pattern is grimly predictable: an MCP server fetches a webpage, the webpage contains adversarial instructions, the agent ingests them as tool output and acts on them. Lock down one server and the next one in the chain becomes the soft target. The protocol doesn't have a clean answer for this because the protocol can't have one — it's downstream of the model's inability to distinguish trusted instructions from untrusted data, which is a model problem, not a protocol problem.

Compare with the code-execution alternative. Hand the agent a sandboxed Python or Node environment, give it a documented set of internal helpers, and let it write a script per task. The auth tokens live in the sandbox's environment. The tool schemas live in code, where they belong. The agent's reasoning is grounded in something concrete (a script it can read back and debug), not an opaque RPC contract. This isn't a new pattern — it's how every senior engineer has always extended their own capabilities, and it turns out agents work better when they extend themselves the same way.

The HN thread surfaced a useful counter-argument worth taking seriously: MCP earns its complexity in stateful, long-running, UI-bound integrations. An IDE plugin that needs to subscribe to file changes, maintain a live document model, and stream completions back to the editor genuinely is a protocol-shaped problem. A one-shot "fetch this Jira ticket and summarize it" is not. The mistake the ecosystem has been making is treating every integration as if it were the first case when 90% of them are the second.

What this means for your stack

If you're building agent-driven workflows in 2026, the practical framing is: default to code execution, escalate to MCP only when state demands it. Concretely:

- For internal API integrations, ship a Python or Node SDK as a file the agent can read, plus a sandboxed runtime. Skip the MCP server entirely. You'll save weeks of work and your auth model will be simpler. - For read-only data fetches (RSS, REST endpoints, S3 reads, database queries), the agent writing a one-line script is almost always faster and more reliable than a tool call routed through an MCP layer. - For genuine stateful integrations — editor plugins, browser automation with session persistence, multi-step UIs — MCP still earns its keep. The protocol is genuinely good at maintaining bidirectional state across a long-running channel. - Audit your existing MCP servers for context-window cost. If a server registers more than 5-10 tools and the agent uses two of them per session, that's pure overhead you're paying for on every request. - Watch what your model provider actually does, not what they say. Anthropic's investment in code execution, file-based skills, and sandboxed environments is a stronger signal about where this is going than any keynote slide claiming MCP is the future of agent tooling.

There's also a hiring signal here. Teams that built their agent stack on "we'll just spin up MCP servers for everything" are now refactoring back to scripts and SDKs. Teams that started with code execution and only adopted MCP for the stateful cases are shipping faster. If you're interviewing for an AI infra role and the team describes their agent architecture as "MCP-first," that's worth probing — not because MCP is bad, but because it's a tell about whether the team chose the architecture or inherited it from a tutorial.

Looking ahead

MCP isn't going to die in 2026 — too many editors and desktop apps depend on it, and the spec genuinely solves the stateful-integration problem well. What's dying is the assumption that MCP is the default way to extend an agent. The default is becoming what it should have been all along: give the model a sandbox, give it some files describing what's available, let it write code. The protocol layer becomes the exception, reserved for the cases where state genuinely needs to live somewhere other than the agent's own scratch space. Quandri's post will be remembered less for the headline and more for naming a shift that was already happening in every serious agent team's architecture diagram.