MCP is dead?

Original Article ↗ Hacker News Discussion ↗

Claims that the Model Context Protocol (MCP) is “dead” have reignited debate over how AI agents should integrate with external tools and services. Commenters weigh MCP’s benefits—standardized, OAuth-friendly access to internal and third‑party systems, centralized distribution of tools and prompts, and suitability for non‑technical users—against its drawbacks, such as context‑window bloat, fragility, overlap with existing APIs/CLIs, and limited real‑world adoption so far. Many expect MCP (or something like it) to persist in enterprise and multi‑user settings, but see lighter‑weight approaches like skills, CLIs, and direct APIs as better fits for individual or developer workflows.

Scope and Timeliness of the Critique

  • Many point out the blog’s measurements are outdated: modern “tool search” and deferred loading drastically cut MCP context overhead.
  • Others note deferred loading is an agent/harness feature, not inherent to MCP, and not universally available.
  • Several complain about undated articles and clickbait framing (“MCP is dead?” then conceding it isn’t).

MCP vs CLI vs Skills vs Plain APIs

  • Repeated argument: MCP is “just an API/protocol” for tools; CLIs and REST still exist underneath.
  • Pro‑CLI/skills side:
    • Skills + scripts are lighter on tokens, easier to reason about, and reuse existing tooling (bash, curl, jq, Python).
    • CLIs are composable, human‑friendly, and already supported by LLMs for popular tools.
    • Adding MCP is seen by some as a fragile extra layer that can drift from the real API/CLI.
  • Pro‑MCP side:
    • Standard, machine‑discoverable schema and interaction model; effectively “OpenAPI for agents plus prompts/resources”.
    • Better distribution story than “git clone some scripts” or teaching people CLIs, especially for non‑developers and mobile clients.

Context Window, Performance, and Reliability

  • Critics emphasize:
    • Large tool definitions and verbose JSON responses can bloat context and slow interactions.
    • Many real MCP servers are unreliable, slow, or poorly designed.
  • Supporters reply:
    • These are harness/implementation issues; MCP can be lazy‑loaded, filtered, or wrapped.
    • CLIs also cost tokens once you include --help outputs and examples in context.
    • Shell one‑liners and ad‑hoc pipelines are more error‑prone than schema‑validated tool calls.

Enterprise Use, Security, and Governance

  • Strong support for MCP in org settings:
    • Central control plane for tools, OAuth/OIDC auth, and fine‑grained allow/deny of operations.
    • Keeps secrets on the server; agents never see API keys; easier audit and telemetry.
    • Useful where no public API or CLI exists, or where shells are disallowed.
  • Skeptics counter:
    • Enterprises already have key management, IAM, and REST standards; MCP can be “a fifth leg”.
    • Real bottlenecks are product UX and management of MCPs in tools like Codex/Claude, which are currently rough.

Hype, Adoption, and Future

  • One side claims “every company is building an MCP server”; others see this as hype echo‑chamber similar to NFTs/blockchain.
  • Some predict MCP is a temporary workaround that will fade as models, shells, and plain APIs improve; others see it solidifying as a de‑facto standard.
  • Broad implicit consensus: MCP is not universally “dead”; it’s one tool among several, with clear strengths in multi‑user/enterprise scenarios and trade‑offs in personal or CLI‑heavy workflows.