Model Context Protocol (MCP): A Universal Standard for AI Application Extensions

anthropic · Tech · 2024 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: AI application extension protocols

AI applications needed a standard way to connect models to tools, data, prompts, memory, and external systems without every client and integration pair building custom one-off adapters.

Constraints:

• The team was solving an M by N integration problem across many AI applications and many external capabilities.
• MCP targets AI applications, not the base models themselves, so client/user control and UI presentation matter.
• Tool calling alone is insufficient because applications also need resources, prompts, sampling, authorization, and stateful interactions.
• Protocol design must be conservative because adding features is easier than removing them without breaking compatibility.
• Remote production servers need authorization, resumable connections, horizontal scaling, and supply-chain trust considerations.

Architecture

MCP defines a client-server protocol for AI applications to consume external capabilities through standardized primitives. Clients are AI applications such as IDEs, Claude Desktop, coding agents, or chat interfaces; servers expose tools, resources, prompts, and later capabilities such as sampling. Tools are model-initiated actions, resources are URI-addressed data/context that may be user-, app-, or model-controlled, and prompts are user-initiated templates or command-like message bundles. The protocol uses JSON-RPC, takes design inspiration from LSP, supports bidirectional communication, and is evolving from long-lived SSE toward streamable HTTP with session resumption. Authorization is based on OAuth-style transport-layer flows, while server trust is treated as an open supply-chain governance problem.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  UI["User interface"] --> Client["AI application client"]
  Client --> Transport["Transport layer"]
  Transport --> Server["MCP server"]
  Server --> Tools["Tools primitive"]
  Server --> Resources["Resources primitive"]
  Server --> Prompts["Prompts primitive"]
  Server --> Sampling["Sampling capability"]
  Server --> External["External service"]
  Server --> Recursive["Recursive MCP client"]
  Recursive --> External
  Client --> Model["Model completion"]
  Tools --> Model
  Sampling --> Client
  Auth["Authorization layer"] --> Transport

Components

Data flow

An AI application connects to one or more MCP servers. The server advertises primitives such as tools, resources, prompts, and sampling capabilities. The client decides how to surface those primitives to the user and model: tools become model-invoked actions, resources can be attached or retrieved into context, prompts become user-triggered templates, and sampling lets servers ask the client for model completions without owning model API keys. Results return through the client-controlled application, and recursive server/client designs can compose multiple MCP servers into richer workflows.

Why this architecture

MCP follows LSP's standardization move: make applications and integrations speak a common protocol so each side can specialize. The team chose JSON-RPC because it is boring infrastructure, then focused design energy on primitives and presentation semantics. Distinguishing tools, resources, and prompts lets application developers build different UI affordances instead of forcing all extension behavior through model-initiated tool calls. Stateful and bidirectional capabilities are retained because the creators expect richer AI applications, agents, and modalities to need state over time.

Models used: Claude · large language models · smaller/faster filtering models · agent frameworks

Scale

• The public launch was around November 25, 2024.
  “When I know November 25th was like the official announcement date”transcript, stated
• The first Zed implementation appeared about a month and a half before the official release.
  “it was there like a month and a half before the official release just because we needed to do it in the open”transcript, stated
• The initial SDK work targeted TypeScript, Python, and Rust.
  “three different languages that we wanted to at least support to some degree. Um that was TypeScript, Python, and then for the Zed integration, it was Rust”transcript, stated
• The speakers describe Claude as able to handle hundreds of tools when names and descriptions are clear.
  “I think hundreds as you referenced is still a fairly safe bet at least for Claude”transcript, stated
• The ecosystem already had about five or six registries by the time of the discussion.
  “there's like five or six different registries already popped up”transcript, stated
• The memory server is described as about 300 lines of code.
  “It's also like 300 lines of code. It's super simple”transcript, stated

Alternatives considered (roads not taken)

Build one-off integrations for every application and service pair

Rejected because: That recreates the M by N problem MCP was designed to solve.

Treat tool calling as the solution for every integration

Rejected because: The creators argue tools are necessary but insufficient; resources and prompts need different application/UI behavior.

Use OpenAPI alone as the LLM integration layer

Rejected because: OpenAPI is useful for APIs, but the speakers say it is too granular and does not express AI-specific primitives.

Require long-lived SSE connections for all remote servers

Rejected because: Persistent connections are operationally hard at scale, so streamable HTTP allows plain HTTP, streaming, server requests, and session resumption.

Add every requested feature directly into the protocol

Rejected because: The team prefers conservative additions because removal is hard once clients and servers depend on a feature.

Patterns

tool-use-orchestration (architecture)

MCP standardizes model-controlled tools so AI applications can invoke external actions through server-provided capabilities.

context-engineering (context)

MCP separates resources and prompts from tools so applications can curate data, schemas, documents, backtraces, and prompt templates into model context through user or app affordances.

rag-retrieval (retrieval)

The designers explicitly envision clients building RAG indexes over documents exposed by MCP resource servers.

agent-memory (memory)

A reference memory server demonstrates cross-conversation memory as an MCP-provided capability rather than a baked-in model feature.

safety-policy-enforcement (governance)

MCP keeps client applications and users in control, adds transport-layer authorization, and treats server trust as a supply-chain security problem.

structured-output-contract (protocol)

The protocol uses JSON-RPC and named primitives as a structured contract between clients and servers.

Tradeoffs

Innovate in primitives while keeping transport boring.

Chose JSON-RPC plus MCP-specific tools, resources, prompts, and sampling over A novel transport or generic API wrapper layer.

Rationale: The team wanted to spend design energy on AI-application primitives and presentation behavior, not on the bytes on the wire.

Retain statefulness while reducing operational burden.

Chose Streamable HTTP with optional streaming, server requests, and session resumption over Pure stateless request/response or always-on SSE.

Rationale: The designers believe richer AI applications will become more stateful, but servers still need simpler deployment and horizontal scaling.

Keep client applications in control.

Chose Client/user control over filtering, presentation, model selection, and sampling over Server-defined behavior that dictates the whole interaction.

Rationale: Application developers need differentiated experiences and users need control over what MCP does on their behalf.

Favor open community governance without formal standardization too early.

Chose Collaborative, merit-driven open-source stewardship over Immediate foundation or standards-body process.

Rationale: The team wants broad participation while avoiding process overhead that slows a fast-moving AI protocol.

Gotchas (what bit them)

Overloading tools loses important application semantics.

Root cause: Many developers default to tool calling for databases, prompts, documents, and context even when resources or prompts would produce a better user experience.

Resolution: Choose primitives based on who should control the interaction: tools for model actions, resources for contextual data, and prompts for user-initiated templates.

Too many overlapping tools can confuse the model.

Root cause: Tool selection quality depends on model capability, naming, descriptions, and overlap between servers such as GitHub and GitLab.

Resolution: Filter at the application layer, use smaller models to select relevant tools, use proxy servers, or give users contextual enable/disable affordances.

Naive remote transports make production operation harder.

Root cause: The original SSE model assumed long-lived persistent connections, which are difficult to operate and scale.

Resolution: Use streamable HTTP with gradual enhancement, streaming, server-initiated requests, and session resumption.

Registry trust can create a supply-chain attack surface.

Root cause: Trusted server listings, downloads, likes, or reviews can be gamed, and updates can compromise previously trusted packages.

Resolution: Treat MCP server discovery like open-source supply-chain security and inspect traffic or server behavior rather than relying only on social proof.

Evaluation

The source evaluates MCP through adoption, implemented clients and SDKs, protocol ergonomics, community contribution, client support for primitives, operational deployability, and whether the protocol avoids known LSP and supply-chain pitfalls.

Metrics: number of clients supporting primitives · SDK coverage across languages · time to build a simple server · number of tools handled without confusion · community contribution quality · remote transport deployability · authorization coverage · server trust and vetting

Outcomes

• MCP launched as a standard protocol for extending AI applications with tools, resources, prompts, and bidirectional client-server capabilities.
• The first IDE implementation appeared in Zed before the official release, and reference servers demonstrated filesystem, memory, sequential-thinking, and other capabilities.
• The ecosystem gained SDKs and contributions from multiple companies and communities, including Microsoft, JetBrains, Pydantic, Shopify, Block, and others.
• The protocol roadmap moved toward streamable HTTP, OAuth-style authorization, session resumption, richer client primitive support, sampling, and server trust tooling.

This is a protocol and ecosystem case rather than a single production deployment. Its scale is reflected in multi-language SDKs, many community servers and registries, hundreds-of-tools discussions, and contributions from multiple companies.