MCP Specification – version 2025-06-18 changes

What MCP Is For vs “Just Use RPC/REST”

  • Ongoing debate over whether MCP adds value beyond plain RPC/REST:
    • Supporters say it standardizes how agents discover and use tools/resources, giving a “plug‑and‑play” way to connect LLM clients to arbitrary backends without bespoke integration each time.
    • Critics see it as “just function calling with extra ceremony,” adding opinionated middleware and security surface where normal APIs or in‑process modules would suffice, especially on backend systems.

Standardization, OpenAPI, and the “USB‑C” Analogy

  • Pro‑MCP arguments:
    • OpenAPI specs in the wild are often incomplete or wrong (poor docs, broken base URLs, ambiguous verbs, messy auth), making them unreliable for tool calling.
    • MCP acts as a signal that an API was designed with LLM use in mind and standardizes things like eliciting user input and auth flows.
    • It enables language‑agnostic integrations (e.g., via stdio) and long‑term ecosystem evolution.
  • Skeptical views:
    • Problems blamed on REST/OpenAPI are largely implementer errors; nothing stops people from misusing MCP in the same way.
    • The USB‑C comparison is seen by some as marketing spin; the real missing standard is model‑side tool‑use APIs (agent→LLM), not server‑side.

Spec Changes and New Features

  • Positive reactions to:
    • Resource links and elicitation (structured user input prompts).
    • Introduction of WWW‑Authenticate challenges and clearer OAuth/authorization story; some community tools emerge to tame auth complexity.
    • Sampling (letting servers call LLMs via the host) and progress notifications, though sampling is viewed as limited and long‑running tasks remain an open design problem.
  • Some disappointment about removal of JSON‑RPC batching, though many concede it mainly added complexity.

Implementation Choices and Practical Pain Points

  • Surprise that the canonical spec is TypeScript; concern about non‑TS implementers, mitigated by auto‑generated OpenAPI.
  • Trend from local stdio “command” servers toward HTTP MCP servers as auth matures.
  • Auth is currently a major friction point; better host‑side logging and dev tooling are requested.
  • Structured output:
    • Clarification that MCP tool results are free‑form media, not forced JSON from the model.
    • Separate argument about LLM JSON reliability: some claim modern constrained decoding makes it a non‑issue, others report frequent schema violations at scale.

Security, Safety, and Scope

  • Prompt injection, evil servers, and data exfiltration are acknowledged as unsolved at the protocol level; commenters argue this requires new model designs, not just protocol tweaks.
  • Concern over proliferating micro‑“servers” per API; countered by suggestions to build monolithic MCP gateways or use third‑party multi‑API hubs.