New MCP Roadmap

Original Article ↗ Hacker News Discussion ↗

Anthropic’s updated Model Context Protocol (MCP) roadmap is prompting mixed reactions from developers, who welcome moves toward stateless, HTTP-based servers and better agent authorization but criticize the spec as overengineered and fragmented in practice. Many argue existing patterns like REST + OpenAPI (or “code mode” with direct HTTP access) are often simpler and more performant, especially for non-interactive workloads, while MCP’s value lies mainly in standardized tool discovery, fine-grained permissions, and enterprise-friendly auth flows. There is broad agreement that long-lived tokens and manual browser approvals don’t scale for autonomous agents, but less consensus on whether MCP is the right abstraction layer or just another complex protocol chasing the AI hype cycle.

Code mode vs MCP

  • Several commenters are moving from MCP-based setups to “code mode” (e.g., Cloudflare’s approach), citing better runtime performance, more flexible orchestration of complex tool calls, and fewer protocol headaches.
  • One person asks for quantitative benchmarks comparing MCP to code mode; no data is provided in the thread, so relative performance impact remains unclear.

Auth, Identity, and Security

  • The roadmap’s focus on DPoP, Workload Identity Federation, and OAuth-based standards triggers debate.
  • Critics see this as overengineering and argue that long-lived tokens stored in secret managers (e.g., 1Password) are simpler.
  • Others respond that long-lived credentials, especially in agents’ hands, are a non-starter for many orgs; complex protocols are seen as necessary for revocation, delegation, and compliance.
  • Enterprise-managed, non-interactive agent auth is a major goal; manual browser approvals are viewed as a scaling bottleneck.
  • Fine-grained, role-like permissions for “sub-entities” (specialized agents) are seen as necessary but UX-challenging.

Protocol Design, Transports, and State

  • Many welcome the move to “MCP over HTTP” and treating MCP like any other HTTP workload; the bespoke v1 protocol is widely criticized as fragmented and confusing.
  • There’s confusion over the future of stdio; best guess from the thread is HTTP over stdio, but this is described as unclear.
  • Some dislike HTTP as the universal IPC layer and prefer a transport-agnostic core protocol; others note gRPC options look heavy.
  • v1’s stateful design is called deployment-unfriendly and hard to test; the move toward statelessness is praised.

MCP vs REST, Skills, and OpenAPI

  • Multiple commenters argue that a well-documented REST API plus a skills/markdown description or OpenAPI spec already works well for agents.
  • MCP’s main added value is described as:
    • Centralized, automatic discovery and updates of tools.
    • Tight alignment between API and tool definitions.
    • Fine-grained, per-tool authorization and easier gating of capabilities.
  • Others counter that enterprises already manage thousands of HTTP endpoints and that MCP adds churn and potential breaking changes without clear payoff.

Complexity, Adoption, and Real-World Use

  • Some see MCP as “jumping the shark” by trying to subsume too much of HTTP and auth; they plan to stick to minimal JSON-RPC-like usage.
  • There’s frustration that early MCP rollout involved multiple partially overlapping standards, context-heavy designs, and inconsistent client support, burning trust.
  • A few still see MCP as promising for narrower, interactive use cases (e.g., securely wrapping privileged APIs, privileged actions via elicitations, and shrinking tool catalogs to reduce context bloat).