The post-MCP agent pattern: thin tools, fat context

What happened

A post titled bluntly "MCP is dead" from Quandri's engineering blog hit 219 on Hacker News and kicked off the sharpest architectural debate the agent space has had this quarter. The argument isn't that Anthropic's Model Context Protocol is bad. It's that for the workload most teams are actually building — narrow, vertical, production agents that do one job well — MCP is the wrong abstraction.

The core complaint is mechanical. Every MCP tool ships a JSON schema, and that schema rides in the system prompt on every single turn of the conversation. Quandri's measurement: a fairly modest MCP server exposing 20 tools burns roughly 10,000 tokens of tool-definition context before the model reads a single character of the user's message. Multiply that by every turn in a multi-step agent loop and the bill, both in dollars and in latency, compounds fast. With long-context models the absolute headroom is there, but as several commenters pointed out, the relevant metric isn't context window — it's the share of attention the model spends parsing tool schemas instead of solving the problem.

The HN thread converged on a more nuanced version of the headline. MCP solves a real problem: a universal protocol for plugging arbitrary tools into arbitrary agents. That problem matters enormously for Claude Desktop, Cursor, and the emerging tier of general-purpose agent shells. It matters much less for the team shipping a single insurance-quote bot, code reviewer, or support triage agent in production.

Why it matters

The post-MCP pattern that's quietly winning in production looks almost retro. A thin set of hand-curated function definitions — three to seven tools, not twenty — combined with a code execution sandbox the model can use for everything else. Anthropic's own "code execution with MCP" guidance from earlier this year nudges in exactly this direction: instead of exposing fifty deterministic tools, expose `run_python` and let the model compose primitives. OpenAI's Code Interpreter has been preaching this gospel since 2023. The MCP critics are now arguing the same thing from the other direction: a Turing-complete escape hatch is more token-efficient than a sprawling tool taxonomy.

The economics back this up. Context-cached tool definitions help — Anthropic's prompt caching can knock 90% off the read cost of stable system prompts — but caching doesn't fix the attention-budget problem. The model still has to consider every available tool at every decision point, and more tools means worse routing decisions, not better ones. This is the same lesson the function-calling literature surfaced two years ago: tool selection accuracy degrades roughly logarithmically with the size of the tool set. MCP made that surface easier to grow, which means most teams who adopted it have probably already overshot.

There's a counterargument worth steelmanning. MCP isn't trying to be the optimal protocol for any single agent — it's trying to be the USB-C of agent tooling. The whole point is that a user can install a Postgres MCP server, a Linear MCP server, and a Jira MCP server into Claude Desktop and have them all just work. You don't redesign USB because a specific embedded device would be faster with a direct GPIO header. For the IDE-and-desktop tier, MCP's overhead is the price of an ecosystem. The Quandri post is really an argument against using a desktop-grade protocol inside a production agent that needs every millisecond and every token.

The community split predictably along build-vs-buy lines. Tool vendors and platform companies — Cursor, Continue, Zed — defended MCP hard, because their entire value prop depends on a universal tool layer. Application teams running their own agents largely agreed with Quandri: they'd ripped MCP servers out of their internal stacks and seen p50 latency drop 30–40% and token cost drop more than half. One commenter framed it well: "MCP is the right protocol for the wrong layer of my stack."

What this means for your stack

If you're building a production agent with a known, bounded job, the prescription is concrete. Audit your tool count: anything above seven tools is probably hurting you, and anything above fifteen is almost certainly hurting you. Collapse related tools into parameterized ones. Move anything that's really "call this HTTP endpoint with these args" into a single `http_request` tool with an allowlist, or better, a code interpreter with the SDK pre-imported. Measure your tool-schema token count as a percentage of every turn; if it's above 20%, you have a refactor on your hands.

If you're building a desktop assistant, IDE plugin, or any agent that needs to integrate with software the user — not you — chose, keep MCP. The protocol's overhead is the cost of letting users bring their own tools, and that's a feature, not a bug. The right mitigation there is aggressive prompt caching, lazy tool loading (only mount the MCP servers relevant to the current task), and a UX that lets users disable servers they're not using. Several of the larger MCP clients are moving toward exactly this — dynamic mounting based on intent classification rather than loading every registered server at session start.

The deeper architectural shift the post points at is the move from tool-as-API to tool-as-capability. A single `run_code` tool with the right SDKs available is more powerful, cheaper, and easier to evaluate than fifty narrow tool definitions. The tradeoff is sandbox engineering: you're now responsible for a reliable, isolated, fast code execution environment, which is non-trivial. But that's a one-time platform investment, not a per-tool tax.

Looking ahead

MCP isn't dying — it's finding its lane. The next twelve months will probably see a clean bifurcation: MCP for ecosystem-grade agent platforms where pluggability is the product, and direct function-calling-plus-sandbox for production agents where every token matters. The teams that win are the ones that stop treating "do we use MCP?" as a yes/no question and start treating it as a layer question. Use it where users assemble their own stack. Don't use it where you assemble the stack for them.