MCP was always a bad idea?

Original Article ↗ Hacker News Discussion ↗

Critics of the Model Context Protocol (MCP) argue it was overhyped and often wastes tokens compared to simply letting AI agents use well-designed HTTP APIs or CLI tools, especially now that models are better at understanding interfaces. Supporters counter that MCP still solves important problems around authentication, least-privilege access, sandboxing, auditability, and standardized tool discovery—particularly in enterprise and multi-user environments where you can’t just hand an agent shell access or raw API keys. The exchange highlights a broader split: solo or local workflows often favor CLIs and direct APIs, while organizational and web-based agent use cases increasingly lean on MCP-style standards and emerging variants like WebMCP.

MCP vs CLI / Direct APIs

  • Many argue CLIs and REST/OpenAPI already solve most problems MCP targets; CLIs are familiar, composable, and often cheaper in tokens.
  • Others say MCP is effectively “REST for agents”: a standard, discoverable interface to tools, better aligned with how agents call tools today.
  • Some see MCP servers as thin wrappers over existing APIs/CLIs (“lipstick on a pig”), adding extra infra without new semantics.

Security, Authentication, and Least Privilege

  • Strong pro‑MCP sentiment around auth: it can hide credentials from agents, centralize auth, and expose only narrow, vetted operations.
  • Critics respond that proper API design, short‑lived scoped tokens, proxies, or sandboxed CLIs can achieve the same—MCP is not uniquely secure.
  • Concern that relying on MCP for access control may create a false sense of security; server‑side controls and auditing are still required.

Token Usage, Context, and Performance

  • Several report MCPs burning more tokens than direct CLI/API use (especially poorly implemented ones); others claim the opposite when MCP schemas are tight.
  • Old MCP design that loaded too much into context is widely criticized; newer “stateless / progressive” variants are seen as improvements.
  • Process‑startup overhead for CLIs is generally considered negligible compared to LLM or network latency.

Enterprise, Governance, and Real‑World Use

  • MCP viewed as most valuable in multi‑user, enterprise settings: centralized control, audit logs, revocation/rotation of secrets, uniform interface across runtimes.
  • MCP plugin stores in major chat apps drive adoption among non‑technical users; some see this as part of an AI “bubble.”

Standards, Alternatives, and WebMCP

  • Several argue existing standards (REST, OpenAPI/Swagger, SOAP/WSDL, HTTP headers, .well-known docs) could have been extended instead of inventing MCP.
  • WebMCP is praised as a simpler, more aligned approach for web apps, potentially superseding “classic” MCP there.
  • Alternatives mentioned: CLI‑centric harnesses, custom sandboxes/VMs, AXI, and generic “make HTTP request” tools with good specs.

Overall Sentiment

  • Consensus: MCP is not universally bad, but overhyped and misused.
  • Rough heuristic from the thread: for solo/local dev, CLIs+APIs usually suffice; MCP becomes attractive when you need cross‑tool standardization, remote access, and centralized governance.