Model Context Protocol (MCP) is an open communication protocol for connecting applications built around large language models to external tools and information sources. It defines standardized messages through which an application can discover available capabilities, retrieve contextual information, and request actions. Introduced by Anthropic in November 2024, MCP separates the interface used by an AI application from the implementation of the systems it accesses. It is an integration protocol, not a language model, a training method, or an autonomous-agent architecture. (modelcontextprotocol.io)
Purpose and scope
AI assistants often need information or capabilities beyond those available within a conversation: files, business records, development tools, or external services. Without a common interface, each application may require separately designed integrations with each system. MCP provides a shared vocabulary for exposing these systems, allowing compatible applications to reuse server implementations rather than independently reproduce every connector. Its design draws inspiration from the Language Server Protocol, which separates programming-language support from individual development environments. (anthropic.com)
MCP standardizes exchanges between software components; it does not determine how a model reasons about the information received. Decisions about model selection, conversation management, context selection, and workflow orchestration remain with the host application. The project includes a protocol specification, software development kits, development tools, and reference server implementations, but these are distinct from the protocol itself. (modelcontextprotocol.io)
Architecture
MCP distinguishes three participants:
- Host: the AI application that coordinates access to external capabilities and manages its MCP clients.
- Client: a component within the host that communicates with a particular MCP server.
- Server: a program that exposes information or functionality through MCP.
A host can communicate with several servers through separate clients. A server may run on the same computer as the host or operate as a remote service; “server” describes its role rather than requiring a separate physical machine. (modelcontextprotocol.io)
The protocol has a data layer, defining messages and their meanings, and a transport layer, defining how those messages are delivered. Its messages use JSON-RPC 2.0, with named methods, structured parameters, request identifiers, results, and errors. This separation allows the same operations to be represented across different communication mechanisms. (modelcontextprotocol.io)
Core capabilities
MCP servers can expose three principal kinds of capability. A server need not implement all three. (modelcontextprotocol.io)
Tools
Tools are executable operations, such as querying a database, calling an application programming interface, or performing a calculation. A tool has a name, descriptive metadata, and an input specification expressed using JSON Schema. Clients discover tools with tools/list and invoke them with tools/call. Results can include text, images, audio, resource references, and structured content. (modelcontextprotocol.io)
Tools are described as model-controlled because a language model can select an operation and generate its arguments. This does not mean that model output directly executes arbitrary operations: the host mediates invocation, and the specification recommends human oversight and interfaces that allow tool calls to be denied. MCP does not prescribe a single user-interface design. (github.com)
The protocol distinguishes malformed or otherwise invalid protocol requests from failures encountered while executing a valid tool call. The latter can be returned as tool results marked with isError, allowing an application to present the failure to the model or user without treating it as a breakdown of protocol communication. (modelcontextprotocol.io)
Resources
Resources are identifiable pieces of contextual information, such as file contents, database schemas, or application records. Each resource has a uniform resource identifier. Clients can enumerate resources using resources/list, retrieve them using resources/read, and discover parameterized resource templates. Resource contents may be textual or binary. (modelcontextprotocol.io)
Resources are generally application-driven: the host decides whether and how their contents enter the model’s context. An application might offer a selection interface, retrieve information automatically, or use model-assisted selection. Resource metadata and access mechanisms do not themselves determine what information the model ultimately receives. (modelcontextprotocol.io)
Prompts
Prompts are reusable message templates supplied by a server. Clients discover them with prompts/list and obtain populated messages through prompts/get, optionally supplying arguments. Examples include templates for reviewing code or analyzing documents. They are intended to be user-controlled, often appearing as selectable commands, although their contents are authored by the server. They provide a reusable interface for prompt engineering rather than modifying a model’s parameters. (modelcontextprotocol.io)
Communication and protocol evolution
The standard transports include standard input/output, commonly used between local processes, and Streamable HTTP, used for network-accessible services. Streamable HTTP carries client messages through HTTP POST requests and can use server-sent events for streaming. Transport bindings specify delivery and framing while preserving the protocol’s message semantics. (modelcontextprotocol.io)
MCP is versioned, and descriptions of its operation must distinguish revisions. In the July 28, 2026 revision, requests are self-contained: each carries protocol-version information and relevant client capabilities in its _meta field. Servers must implement server/discover, which reports supported versions and capabilities, but clients may issue other requests without first performing discovery. This differs from older revisions organized around an initialization handshake and protocol-level sessions. (modelcontextprotocol.io)
Stateless protocol requests do not prohibit stateful applications. A service can maintain a shopping cart, browser context, or other continuing operation by returning an explicit identifier that subsequent tool calls supply as an argument. Such application state is distinct from implicit state associated with a protocol connection. (modelcontextprotocol.io)
Additional functionality depends on the revision and supported extensions. The July 2026 specification includes user-input elicitation and optional extensions for long-running tasks, structured workflow instructions, and interactive interfaces. Sampling—through which a server could request a model completion from the client application—is deprecated in that revision. Implementations therefore cannot assume that every feature described in earlier MCP documentation remains part of the current core protocol. (modelcontextprotocol.io)
History and governance
Anthropic announced MCP on November 25, 2024, releasing it as an open-source approach to connecting AI assistants with repositories, business tools, and development environments. The initial announcement included protocol specifications, development kits, and integrations intended to demonstrate reusable connections between assistants and external systems. (anthropic.com)
On December 9, 2025, the Linux Foundation announced the Agentic AI Foundation, with MCP among its founding project contributions. Anthropic donated MCP to this foundation, establishing a vendor-neutral organizational home for its continued development. This governance arrangement is separate from the commercial products that implement the protocol. (linuxfoundation.org)
Applications and boundaries
MCP supports integrations for software development, document access, database interaction, and business workflows. For example, a database server can expose its schema as a resource, offer query operations as tools, and supply prompts explaining a workflow. Remote servers can also expose hosted services while retaining service-specific access controls. (modelcontextprotocol.io)
MCP and retrieval-augmented generation address different architectural concerns. MCP defines an interface for obtaining information and invoking operations; retrieval-augmented generation describes using retrieved information to support generation. Thus, as an architectural distinction, an MCP server can provide retrieval capabilities within such a system, but MCP does not itself specify document indexing, retrieval ranking, or answer generation. Its scope remains context exchange rather than the host’s use of that context. (modelcontextprotocol.io)
Similarly, MCP tool invocation is distinct from a model provider’s tool-calling interface. The host may translate discovered MCP tools into the format accepted by its chosen model and translate model-generated calls back into MCP requests. Standardizing the external interface does not eliminate the need for host-side integration or compatible capability support. (modelcontextprotocol.io)
Security and limitations
MCP connects language-model applications to potentially sensitive information and executable operations, making cybersecurity and data privacy central implementation concerns. The specification calls for user consent, access controls, and careful handling of tool execution. It explicitly states that these principles cannot be enforced by the protocol alone. Descriptions and annotations received from an untrusted server are not guarantees of safe behavior. (modelcontextprotocol.io)
For HTTP-based deployments, MCP defines an authorization framework based on OAuth. Authentication and authorization remain separate from the model’s decision to request an operation: a plausible tool call does not establish permission to access the underlying service. The security documentation addresses risks including token passthrough, confused-deputy behavior, and server-side request forgery. (modelcontextprotocol.io)
Resource access introduces additional risks. The specification requires validation of resource identifiers and protection against directory traversal when serving file-like resources. Prompt inputs and outputs also require validation against injection attacks and unauthorized access. Consequently, protocol compatibility is not equivalent to trustworthiness: safety depends on the server implementation, the host’s mediation, credentials, and the permissions of the underlying systems. (modelcontextprotocol.io)
References
- Introducing the Model Context Protocolanthropic.com
- Specificationmodelcontextprotocol.io
- Architecture overviewmodelcontextprotocol.io
- Toolsmodelcontextprotocol.io
- Resourcesmodelcontextprotocol.io
- Promptsmodelcontextprotocol.io
- Transports: Overviewmodelcontextprotocol.io
- Authorizationmodelcontextprotocol.io
- Security Best Practicesmodelcontextprotocol.io
- What's Changed in MCP: The 2026-07-28 Specificationgithub.com
- Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions Including Model Context Protocol (MCP), goose and AGENTS.mdlinuxfoundation.org
- MCP joins the Agentic AI Foundationblog.modelcontextprotocol.io