AI Trend Notifier
EN한
← wiki

$ cat wiki/concepts/mcp.md

MCP — Model Context Protocol

conceptupdated 2026-08-02created 2026-07-29
mcpagentstool-useprotocolinteroperabilityoauth

Definition

An open protocol that standardizes how AI applications connect to external tools, data sources and services. A client (the AI application) talks to servers that expose tools (callable functions), resources (readable data) and prompts (reusable templates) over a common wire format, so an integration written once works with any MCP-speaking client.

Originated at Anthropic and now maintained as an open specification with a multi-vendor SDK set (TypeScript, Python, Go, C#; Rust in beta) (source).

Why It Matters

  • It is the integration layer the agent ecosystem settled on. MCP passed 400M monthly SDK downloads, a 4× increase over the year, and is used as the connection standard across competing agent products (Claude blog).
  • Protocol decisions propagate into every deployment. The 2026-07-28 revision changes how servers scale and how they authenticate; every remote MCP server inherits that change rather than choosing it.
  • It is where agent security is actually enforced. Authorization, tool permissions and gateway routing are protocol-level concerns, which is why the authorization rework below matters more than its size suggests. → AI-Enabled Cyberattacks

State of the Art (2026-08-02)

The 2026-07-28 specification

Released July 28, 2026 — the largest revision since the protocol was published. It moves the core from a bidirectional stateful protocol to a stateless request/response model (source).

Stateless core. The initialize/initialized exchange and the Mcp-Session-Id header are gone; sessions are removed (SEP-2567). Each request carries its own protocol version, client identity and capabilities. Servers that need cross-call state now mint explicit, server-issued handles passed as ordinary tool arguments. The practical effect: a remote server that previously required sticky sessions and a shared session store can run behind a plain round-robin load balancer, on serverless or on edge infrastructure.

Multi Round-Trip Requests (MRTR). Replaces server-initiated requests that needed an open stream. A tool needing user input mid-call returns resultType: "input_required"; the client retries with answers in inputResponses.

Header-based routing. Mcp-Method and Mcp-Name HTTP headers let gateways route and authorize without parsing JSON bodies.

Cacheable list results. tools/list, resources/list and prompts/list no longer vary per connection and carry ttlMs and cacheScope, so clients can cache them.

Authorization hardening. Six SEPs align the spec with production OAuth 2.0 / OIDC: RFC 9207 issuer validation on authorization responses (SEP-2468), a shift from Dynamic Client Registration (DCR) to Client ID Metadata Documents (CIMD), and client credentials bound to their issuing authorization server. MCP servers can now connect to enterprise identity systems such as Entra or Okta without workarounds.

Extensions framework. Tasks, MCP Apps and Enterprise Managed Authorization (EMA) become versioned extensions, so interactive UIs and long-running work can be added without changing the core. The Tasks extension is rebuilt around statelessness: a server answers tools/call with a task handle and the client drives it via tasks/get, tasks/update and tasks/cancel.

Deprecations. Roots, Sampling and Logging are deprecated with a 12-month minimum transition period; the legacy HTTP+SSE transport is also deprecated.

Migration. A server that relied on the session header or the initialize handshake must read protocol version and capabilities from _meta, implement server/discover, and attach ttlMs / cacheScope to list and read results. Gateways should route on Mcp-Method / Mcp-Name rather than session affinity.

Client adoption

Claude expanded support for the 2026-07-28 spec on release day — stateless core, the OAuth/OIDC authorization changes, and the versioned Apps and Tasks extensions (Claude blog). → Anthropic

Independent tooling response (2026-07-31)

Three days after the specification, Simon Willison published "Stateless MCP has recaptured my interest" and released tooling built against the new core: mcp-explorer, a stateless Python CLI for interactively probing an MCP server, and datasette-mcp. His stated reasons match the specification's own rationale rather than restating it — stateless MCP is cleaner to implement on both sides, and a better fit for scalable web applications because there is no server-side state to keep and no need to route a session back to the same backend machine (source).

This is the first adoption evidence recorded here from outside the vendors who wrote the spec. It is a small sample — one developer, two tools — but it is the operational claim being tested by someone with no stake in it, and within days rather than across the 12-month deprecation window.

Open Problems

  • A 12-month deprecation window is not a migration plan. Roots, Sampling, Logging and HTTP+SSE all have replacements, but the ecosystem's long tail of small servers has no forcing function until the window closes.
  • State did not disappear, it moved. Server-issued handles passed as tool arguments put session lifetime into application code, where it is neither standardized nor inspectable by a gateway.
  • Cacheable lists assume stable tool sets. ttlMs is a server's promise about its own volatility; a server whose tools change per user or per entitlement has to set it conservatively or serve stale capability lists.
  • Authorization alignment raises the floor, not the ceiling. CIMD and issuer validation fix client-identity weaknesses; they say nothing about whether the tools a server exposes should be callable by a given agent.

Key Papers

Referenced by

Agentic Reinforcement LearningAgents (LLM Agents)AI GovernanceAnthropicClaude Managed AgentsSkill Self-Play: Pushing the Frontier of LLM Capability with Co-Evolving SkillsWeekly Synthesis — W31 (July 27 – August 2, 2026)

Sources