MCP is dead; long live MCP

Original Article ↗ Hacker News Discussion ↗

MCP (Model Context Protocol) is emerging as a de facto standard for letting AI agents securely call tools and access organizational data, but it’s facing backlash from developers who prefer simpler patterns like CLIs plus “skills” files and conventional APIs. Supporters argue MCP’s centralized auth, telemetry, structured schemas, and org-wide consistency are critical for enterprise AI, especially when non-technical users and hosted environments are involved. Critics counter that MCP adds complexity, context bloat, and a new maintenance layer without solving problems that existing protocols, sandboxes, and good CLIs couldn’t already handle.

Overall sentiment on MCP

  • Thread is split: some see MCP as a simple, well‑timed standard that solves real integration problems; others view it as unnecessary, over/under‑engineered, and hype‑driven.
  • Many agree the protocol itself is relatively simple (JSON‑RPC over HTTP + OAuth) but complain that client implementations and ecosystem are immature and buggy.

MCP vs CLI / Skills

  • Pro‑CLI side:
    • CLIs plus “skills”/docs can give agents discoverable, lazily‑loaded capabilities without bloating context.
    • Unix‑style piping, filtering, and heredocs are powerful and cheap in tokens.
    • Once agents can run bash in a sandbox, an extra protocol layer feels like overhead; traditional API gateways and CLIs already support auth, RBAC, and auditing.
  • Pro‑MCP side:
    • Standardized schemas, resources, prompts, and output types make tool use more reliable and compress context better, especially with code‑execution agents.
    • Remote MCP avoids per‑environment installation, works on mobile and non‑desktop clients, and fits environments where agents cannot run arbitrary commands.
    • Structured, discoverable tools beat ad‑hoc parsing of --help or SKILL files, particularly for non‑technical users.

Enterprise, centralization, and security

  • Supporters argue MCP is well‑suited for orgs:
    • Centralized tool catalogs, shared docs/prompts, telemetry, and OAuth‑based auth.
    • Clear capability boundaries and potential for auditability and least‑privilege “gates” between LLM decisions and deterministic actions.
  • Critics counter:
    • Existing API specs, CLIs, and proxies already deliver centralization and observability.
    • MCP shipped without solid auth initially; some enterprises now ban it due to lack of a clear authentication standard.
    • Security of MCP servers and agents remains an open, non‑trivial problem.

Context bloat and routing

  • A common complaint: naïve MCP clients load too many tools and return huge blobs, blowing context windows.
  • Proposed mitigations:
    • Tool search/list/get‑details patterns, BM25/semantic routing proxies, sub‑agents with restricted tool sets, and better server design.

Use cases and practicality

  • Successful use cases cited: debugging datastores and microservices, browser/desktop automation, VCS and CMS workflows, custom language tools, shared org‑wide knowledge via resources/prompts.
  • Skeptics emphasize maintenance burden (stale MCP wrappers, poor client support) and argue skills + HTTP/CLI remain simpler and more robust for many developer‑centric workflows.