What Is the Model Context Protocol? A Practical 2026 Guide

The Model Context Protocol (MCP) is an open protocol for connecting an AI application to systems that can provide context or perform work. A coding assistant can use it to inspect a repository, a support assistant can retrieve a customer record, and a general-purpose host can connect to several specialized services without inventing a different integration contract for each one.

This page defines the protocol as a whole. For the server-specific beginner journey, use the complete guide to what an MCP server is.

The protocol standardizes the boundary between an AI host and an MCP server. It defines messages, capability discovery, results, errors, transports, and security responsibilities. It does not prescribe which model to use, how an agent should reason, or whether an application should call a tool in the first place.

That distinction matters because MCP changed substantially after its 2024 launch. As of this page’s August 25, 2026 review, the current 2026-07-28 specification is stateless at the protocol layer S054. Many tutorials still describe the initialization sessions used by the 2025 and older protocol. This guide labels those differences instead of blending them together.

What problem MCP actually solves

Models already had ways to request function calls before MCP. OpenAI documented function calling in 2023 S010, while product-specific plugin systems paired manifests, APIs, and OAuth S009. Those mechanisms helped a model or one product use a tool, but they did not create a shared protocol through which many hosts could discover and use many independently implemented context providers. The full MCP vs function calling comparison separates model intent, host orchestration, protocol, and underlying API layers.

MCP addresses that integration boundary. A server can describe what it offers in a standard form; a compatible host can connect, inspect those capabilities, and exchange JSON-RPC 2.0 messages S001. The design drew explicitly on the Language Server Protocol pattern: one standardized interface allows editors to work with many language servers. MCP applies a related separation to AI hosts and context servers, an influence visible in the first public specification commit S002 S013.

This gives three practical benefits:

1. Portability. A server can target the protocol rather than one model vendor’s private integration format.
2. Separation of concerns. The host owns model orchestration, user consent, and policy; the server owns a focused integration.
3. Composability. One host can manage multiple clients, each connected to a different server, without merging every service into one privileged process.

MCP is therefore an interoperability layer, not a universal agent runtime. A system may use MCP alongside a model provider’s tool-calling API, ordinary HTTP APIs, queues, databases, and an agent-to-agent protocol.

Hosts, clients, and servers

The dedicated host, client, and server architecture guide compares the three roles, where the LLM sits, logical versus physical topology, product classifications, and the 2026 redesign.

The current MCP architecture retains a client-host-server model. The names describe protocol roles, not necessarily separate machines.

One host can create several client instances, but each client has a one-to-one relationship with a server. That boundary helps prevent one server from automatically seeing another server’s data. The host remains the coordinator and should show users what is being accessed or executed.

“Stateless” has a narrow meaning here. In the 2026 protocol, each request is self-contained and carries the metadata needed to interpret it. It does not mean a server cannot use a database, issue an application-level handle, or continue a long-running job. It means MCP no longer relies on a protocol session established by an initialization handshake. The official versioning document calls 2026-07-28 and later implementations modern, 2025-11-25 and earlier implementations legacy, and implementations that support both dual-era S056.

Tools, resources, prompts, and extensions

MCP is often summarized as a tool protocol, but the launch specification exposed several distinct primitives S024:

• Tools are callable operations. They have names, descriptions, and input schemas, and can return structured content. A tool might create an issue, query a database, or run a build. The June 2025 specification added structured output and output schemas S045.
• Resources are addressable context, identified by URIs. They can represent files, records, schemas, or other readable material; servers may also publish resource templates S029.
• Prompts are server-provided templates for user-controlled workflows. They are not hidden system prompts and do not force the host to run anything S030.

The protocol also defines ways to discover those capabilities and receive changes. On the client-facing side, earlier MCP revisions included roots, sampling, and elicitation. Roots communicate relevant project or filesystem boundaries S031; sampling lets a server ask the host for model work S032; elicitation lets it request additional user input S046.

In the 2026 core, requests for roots, sampling, or elicitation are represented through the multi-round-trip result pattern rather than unsolicited server-to-client JSON-RPC calls. Roots and Sampling remain functional but are formally deprecated for new implementations; they were not abruptly removed. Optional features can also live outside the core. MCP Apps provides sandboxed server-supplied interfaces S059, while Tasks became the io.modelcontextprotocol/tasks extension S060.

The useful mental model is: core MCP defines the interoperable exchange; capabilities and extensions define what a particular connection can do. When behavior depends on an optional feature, a client should use discovery or handle the defined unsupported response rather than assume every server supports it.

How a current MCP exchange works

A modern exchange normally follows this sequence:

1. The host decides which server may be used and creates a client for it.
2. The client sends a JSON-RPC request over a supported transport. Every request declares the protocol version and client capabilities in _meta; HTTP also carries the version in the MCP-Protocol-Version header.
3. The server either returns a completed result, returns a defined error, or says more input is required.
4. If input is required, the host obtains the user, model, or root information and retries the original request with that information. This is the 2026 Multi Round-Trip Requests pattern S062.
5. The host decides how returned data enters model context and whether a proposed action should proceed.

Servers must implement server/discover, allowing modern clients to learn supported versions. A client can also make its preferred request immediately and, if it receives an UnsupportedProtocolVersionError, retry with a mutually supported version S056.

For transport, local integrations commonly use stdio, where the host launches a server process and exchanges messages through standard input and output. The standard remote binding is Streamable HTTP. The 2026 binding still permits streamed responses, but removed protocol sessions and the Mcp-Session-Id header S057. Stateless protocol semantics and streaming transport are not opposites.

Current MCP versus legacy MCP

The following boundary prevents most version confusion:

The legacy design was not an error. At launch, MCP negotiated protocol versions and capabilities during initialization S024, and the March 2025 Streamable HTTP design intentionally supported stateful sessions and optional SSE S038. The 2026 changelog records the later tradeoff S055: self-contained requests are easier to route, cache, and scale behind ordinary infrastructure. Our 2026-07-28 migration guide covers the mechanical changes in detail, while the MCP history explains how the design arrived there.

When MCP is—and is not—the right abstraction

MCP is a good fit when an AI host needs a reusable boundary to several data or action providers; when the same integration should work across multiple compatible hosts; or when local-process and remote-service integrations should share one conceptual model. It is especially useful when discovery, schemas, versioning, user consent, and capability negotiation would otherwise be rebuilt repeatedly.

It is not automatically the right answer for service-to-service traffic with no AI host, a private one-off function inside a single process, or direct communication between autonomous agents. Google’s A2A protocol, for example, was introduced for agent-to-agent interoperability and described as complementary to MCP S118. An application can reasonably use both at different boundaries.

Nor does compatibility imply trust. Tool descriptions can influence model behavior, and security researchers have demonstrated tool-poisoning, rug-pull, and shadowing attacks S108. A host must treat server metadata and outputs as untrusted, constrain authorization, show consequential actions to users, and avoid granting a server broader credentials than its task requires.

The durable definition is therefore simple: MCP is a standardized protocol boundary through which an AI host discovers and uses context and capabilities supplied by specialized servers. Everything else—transport, extensions, model provider, interface, and deployment—is an implementation choice that must be evaluated against a specific protocol version.