A critical look at MCP

Original Article ↗ Hacker News Discussion ↗

What MCP Is and How It Differs from Existing Approaches

  • Many describe MCP as “JSON‑RPC with predefined methods for LLMs”: an RPC standard with built‑in tool discovery and metadata that clients can query (tools, resources, prompts).
  • Supporters argue this is better than OpenAPI for LLMs:
    • Tool descriptions are much shorter than full OpenAPI specs, saving tokens.
    • The LLM stays in its “text out” paradigm; an engine interprets tool calls.
    • Specs can be dynamic and session-based (tools added/announced at runtime).
  • Skeptics counter that:
    • OpenAPI + dynamic serving and /.well-known already solve discovery.
    • MCP tool lists are trivially convertible to OpenAPI; MCP adds complexity without clear new capability, especially for remote servers.

Transport Layer and Statefulness

  • Major controversy centers on transports:
    • Stdio is seen as simple and Unix‑like, but brittle for larger systems and hard to combine with existing servers.
    • HTTP+SSE / “Streamable HTTP” is widely criticized as an overengineered attempt to emulate a bidirectional socket using separate read/write endpoints and session IDs.
    • Several argue WebSockets (or plain TCP) are the obvious fit for full‑duplex, stateful interaction; the published reasons “why not WebSockets” are called weak or misguided.
  • Others defend HTTP-based designs as friendlier to serverless, firewalls, and modern infra, though even supporters note that MCP’s “statelessness” is leaky (sessions, resume tokens, sampling).

Spec Quality, Tooling, and Security

  • Recurrent theme: the spec site is vague, reads like LLM‑generated marketing, and forces developers to reverse‑engineer SDKs and schemas.
  • Concerns:
    • Underspecified behaviors (e.g., how exactly streaming, sessions, and resumability work).
    • Multiple entry points and transports increasing attack surface.
    • Difficulty auditing logging, state, and data flows when hidden behind SDKs.
  • MCP authors and contributors respond that:
    • It’s very early; auth and other parts are being revised with input from security experts.
    • OAuth 2.1–style flows are recommended for non‑local servers; local/stdio can remain simpler.

Developer Experiences and Adoption Dynamics

  • Many implementers report painful experiences: broken SDKs, unclear errors, non‑working servers in registries, and brittle stdio behavior.
  • Others report strong practical wins: very low barrier to writing simple servers, rapid tool wiring, and non‑developers successfully exposing data sources to LLMs.
  • Several frame MCP as “worse is better”: technically messy but good enough to ignite a tooling ecosystem; fear is that early design mistakes will ossify and be hard to undo if MCP becomes the de facto standard.