MCP is dead: why agents only ever needed OpenAPI and curl

What happened

A post from Quandri's engineering blog titled bluntly *MCP is dead* climbed to 281 points on Hacker News this week, with a comment section that read less like a debate and more like a confession. The thesis is simple: the Model Context Protocol solves a problem large language models stopped having around the launch of GPT-4's function calling — namely, how to describe a tool to a model in a structured way. Quandri's argument, built from running real agents in production for insurance brokerage automation, is that MCP adds a server, a transport, a schema layer, and a discovery protocol to do what an OpenAPI spec and a `fetch()` call already do, with worse ergonomics and a smaller ecosystem.

The specific claims are concrete. Quandri ran an internal bake-off between an MCP-mediated agent and one that consumed raw OpenAPI specs through tool-use. The OpenAPI agent had fewer moving parts, lower latency (no extra hop through a local MCP server), and — critically — better tool-selection accuracy because the model could reason directly about HTTP verbs, status codes, and error bodies it had seen ten million times in training. The MCP version required maintaining a separate process, a separate auth boundary, and a separate failure mode for every integration.

The HN thread surfaced the broader pattern. Engineers from Stripe, Vercel, and several YC companies posted variants of the same observation: they shipped MCP servers because of the discourse, then quietly ripped them out when the agent worked better without them. One top comment summarized it cleanly: *"MCP is a solution looking for a problem that function calling already solved."*

Why it matters

The protocol-vs-primitive debate is the oldest fight in distributed systems, and it always plays out the same way. Someone invents a higher-level abstraction to standardize an emerging behavior; the underlying primitive evolves to absorb the use case; the abstraction becomes a liability. SOAP lost to REST. CORBA lost to JSON-over-HTTP. gRPC won inside the datacenter and lost at the edge. MCP is now playing the role of SOAP in this morality play, and the model providers themselves are quietly playing the role of REST.

The technical case against MCP-as-mandatory is harder to dismiss than its defenders want to admit. When Anthropic launched MCP in late 2024, function calling was still fragmented across providers — OpenAI's spec, Anthropic's spec, Google's spec, each subtly incompatible. MCP made sense as a *Rosetta Stone*. But by mid-2025 every major model had converged on OpenAPI-shaped tool definitions, and the convergence happened in the model layer, not the protocol layer. Claude 4, GPT-5, and Gemini 2.5 all natively reason about OpenAPI documents handed to them as context. The standardization MCP was supposed to enforce happened inside the weights instead.

This is where Quandri's bake-off data gets uncomfortable. They measured tool-selection accuracy on a 200-task benchmark against their own production API surface. The OpenAPI-direct agent picked the right endpoint 94% of the time; the MCP-wrapped version of the same API hit 87%. The seven-point gap came almost entirely from MCP's tendency to flatten REST semantics into a generic *call_tool(name, args)* shape, stripping the model of context it had spent its training run learning to use.

The counter-argument from MCP proponents is real but narrower than the marketing suggests: MCP gives you a uniform auth and capability-discovery layer across heterogeneous tools, which matters for desktop agents stitching together filesystems, browsers, and SaaS APIs from a dozen vendors. Claude Desktop's MCP integration genuinely works for that. But that's a specific topology — local-first, multi-vendor, untrusted — and dressing it up as the future of agent tooling oversold the case. Server-side agents calling your own APIs don't need a discovery protocol; they need a `requirements.txt`.

What this means for your stack

If you're building agents that primarily call your own services, default to OpenAPI plus native function calling. The pattern is now boring: maintain an OpenAPI 3.1 spec for your internal API, pass the relevant subset into the model's tool definitions at request time, let the model emit structured tool calls, execute them with a plain HTTP client. Total new infrastructure: zero. The model is already trained on millions of OpenAPI documents; lean on that.

If you're integrating with third-party services that *already* ship MCP servers — and only if — using their MCP integration is the path of least resistance. But don't build your own MCP server to wrap APIs you control. You're adding a hop, a process, and a schema translation for the benefit of an abstraction the model doesn't need. The honest rubric: if you wouldn't build a SOAP wrapper around your REST API, don't build an MCP server around it either.

For the desktop-agent case — Claude Desktop, Cursor's agent mode, Zed's AI features — MCP remains the practical choice because the alternative is shipping a custom plugin protocol per app. That's a legitimate use, and one Anthropic should keep investing in. But it's a desktop interop story, not the universal agent fabric the protocol was originally pitched as.

Looking ahead

The interesting question isn't whether MCP survives — it will, in the desktop and multi-vendor niches where capability discovery is genuinely hard. The question is whether the agent ecosystem learns the lesson the web learned in 2005: when the underlying primitive is good enough, the elaborate protocol on top of it is dead weight. Quandri's post is a leading indicator, not a contrarian take. Watch for the framework consolidation over the next two quarters — LangChain, LlamaIndex, and the Vercel AI SDK are all already prioritizing direct OpenAPI tool definitions over MCP server scaffolding. The protocol layer is collapsing back into the model, exactly where it belongs.