Skip to content

Case Against MCP

armin-ronacher's 2026 position (endorsed by mario-zechner): MCP is the wrong abstraction layer for most of what people want it to do. Converges with skills-over-mcp from the alex-krentsel / openclaw side but comes at it from the code-execution angle.

Core objections

  • The model doesn't really see MCP tools. "It's basically RAG — input in, do some stuff, maybe some state transition the model also doesn't see." The agent can't reason compositionally about MCP tools because the tool semantics are opaque to it.
  • Agents are extremely good at running code, MCP is not quite running code. If the model can write a Python script that calls the API, the MCP is a lossy intermediary. Armin has "found ways to make MCP composable by having the MCP be one tool: run_code. I haven't found ways to orchestrate larger ones."
  • No composition story. MCP tools don't compose reliably across servers because the protocol doesn't give the model a shared substrate to combine them in.

What Armin would rather have ("MCP2")

  • OAuth — take the legitimate win MCP added to the ecosystem (auth discovery, token flow) and keep it.
  • Generated SDK libraries (Stainless-style, from OpenAPI specs) — so the model writes ordinary code against ordinary APIs.
  • Or direct HTTP requests against OpenAPI specs — the specs already exist, models already read them, compose from there.

Net: push the abstraction one layer down, from "MCP tool" to "authenticated HTTP + generated client." Let code-execution be the composition primitive.

Where MCP still makes sense

  • Enterprise / compliant environments where code execution is not permitted and a pre-vetted RAG-shaped tool surface is the only acceptable interface.
  • Auth-heavy server integrations where the OAuth discovery flow is itself the feature.

Connects to