MCP vs. API Explained

Original Article ↗ Hacker News Discussion ↗

What MCP Is (According to the Discussion)

  • Seen primarily as a protocol for dynamically loading tools into LLM-based applications at runtime, rather than a replacement for normal APIs.
  • Under the hood, it’s mostly a JSON-RPC convention plus manifests, used by “hosts” (Claude Desktop, Cursor, etc.) to discover tools from “MCP servers” and expose them as model tools.
  • Key value: users—not just developers—can add or swap capabilities while the app is running, analogous to browser extensions or an “App Store for agents.”

Perceived Use Cases and Real-World Integrations

  • Concrete uses mentioned:
    • Browser debugging tools from within Cursor (console/network logs, screenshots).
    • Local search via searxng.
    • Connecting memory apps or Unity to coding agents.
    • Hugging Face Spaces access, image/audio services, dev‑workflow automation (Jira/Linear/Sentry/Notion/Slack, PR summaries).
  • Several commenters tried the filesystem server and found it clunky or inaccurate; others “haven’t found anything useful yet.”
  • Some view it as mainly the extension API for a few agent IDEs, not something app builders generally need.

Comparison to APIs, SDKs, and Other Protocols

  • Frequently compared to: APIs/SDKs, OpenAPI/Swagger, SOAP/WSDL, HTML/HATEOAS, LSP, FTP, and various “one API to rule them all” attempts.
  • Pro-MCP arguments:
    • Standard “AI SDK” shared across hosts and models.
    • Pre-trained pattern lowers token cost and error rate vs. having LLMs read arbitrary docs or auto-generate clients.
    • Simpler, more constrained than typical public APIs; tuned to how LLMs actually use tools.
  • Skeptical arguments:
    • Feels like yet another API description layer; most of this could be done with OpenAPI + codegen or normal SDKs.
    • If LLMs can’t reliably consume existing API docs, that undercuts claims of broad “intelligence.”

Design, Security, and UX Concerns

  • Critiques of over-structure and complexity; fear it may be a “local minimum” that loses to something more web‑like and flexible.
  • Current spec seen as weak on auth and odd in orchestration (clients spawning/managing servers).
  • Discovery and UX for non-technical users (finding/adding servers, registries) are unresolved but active areas (registries, inspectors, hosting platforms emerging).

Critiques of the Article Itself

  • Many found the article shallow: reused metaphors, vague explanations, suspected LLM-generated text, and missing important context (Anthropic origin, practical examples).
  • Multiple readers called for concrete, data-backed examples and clearer differentiation from plain APIs.