MCP is the coming of Web 2.0 2.0

Original Article ↗ Hacker News Discussion ↗

Status of MCP as a “Standard”

  • Debate over calling MCP an “open standard”: critics note no standards body or formal governance; others counter that de facto standards often precede formalization and can be “more open” than paywalled specs.
  • Some see MCP already as a de facto standard due to rapid adoption; others argue versioning and security maturity are still lacking.
  • Clarification that MCP uses date-based spec versions and has evolving transports (SSE, optional WebSocket) and session management.

Security and Protocol Design Concerns

  • Strong criticism that MCP launched without serious security, especially for anything exposed beyond localhost; calling this “Web 1.0 thinking.”
  • Supporters argue many initial use cases are purely local and that “perfect security first” would stall experimentation; opponents say this repeats past mistakes.
  • Sandboxes (e.g., hosted MCP runtimes) are viewed by some as partial mitigation, by others as a workaround that doesn’t fix fundamental design issues.

Economics, Incentives, and Openness

  • Many expect MCP to face the same pressures as Web 2.0 APIs: paywalls, auth layers, rate limits, and consolidation around a few large “mega-MCP” providers.
  • Thread repeatedly returns to “nobody makes money when things aren’t locked down” or at least incumbents don’t; open endpoints risk resource exhaustion.
  • Suggested stable model: pay-per-call RPC, likely mediated by the model/agent provider; skepticism that small independent MCP servers will survive.

Comparisons to Semantic Web, Web 2.0, and APIs

  • MCP is framed as “APIs V2” or “robots.txt evolved”: a way to describe usable resources/tools for agents.
  • Some argue Semantic Web failed due to lack of incentives and metadata authoring burden; LLMs plus plain text are seen by others as the pragmatic successor.
  • Prior dreams like HATEOAS and RDF are cited as cautionary tales; criticism that MCP repeats design issues (JSON-only, weak flow control, no built-in payments).

Use Cases and Practical Value

  • Many think MCP is best suited for enterprise “glue” work: orchestrating messy internal systems where LLMs can sit between heterogeneous APIs.
  • Others see its near-term value in automated testing and internal tooling, not public consumer web APIs.
  • Consensus that MCP is essentially an RPC layer for chat/agents, not a TCP-for-AI-level revolution.

Context, Semantics, and LLM Interaction

  • Ongoing debate: should models “pull” context via MCP (agent discovers APIs and data) or should humans/systems “push” carefully curated context into prompts?
  • Some argue LLMs are good at discovering how to use complex APIs (given OpenAPI/GraphQL/etc.); others report better results when humans handcraft context.
  • XML, RDF, and schema exposure (including SQL DDL) are floated as ways to resurrect a more practical “Semantic Web” when combined with LLMs and MCP.

Future Trajectory and Risks

  • Strong fear of “enshittification”: initial user benefit followed by lock-in and rent-seeking, especially as every MCP call routes through monetized LLMs.
  • Skeptics see current hype as another Bay Area buzz cycle; optimists argue this community can still push MCP toward more user-centric, interoperable systems.