Ask five sources what the main components of MCP are, and you’ll get three different answers: three, four, or five. That’s not a rounding error. Some are answering “who’s talking” and some are answering “what gets exchanged,” and most don’t say which question they’re actually answering. One widely cited comparison lists “tools, resources, prompts, transports, and a handshake mechanism” as five core components. Another adds a “context store” as a fourth participant alongside host, client, and server, a term that doesn’t appear anywhere in the specification’s own vocabulary. A third piece, still ranking, describes sampling as a defining capability of the protocol. As of the July 28, 2026, revision of the specification, sampling is deprecated, and the connection-time handshake is gone.
None of that makes those sources wrong about MCP generally. It makes them imprecise about this specific question in ways that compound the longer the industry keeps citing each other instead of the spec itself.
Model Context Protocol Components: What They Standardize for AI Systems
Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, for connecting AI systems to external data sources and tools through one consistent interface instead of a custom integration per pairing. The common illustrative framing: without a standardized protocol, connecting N AI applications to M tools requires roughly N times M separate integrations; MCP’s promise is collapsing that to roughly N plus M, one integration per side rather than one per pairing. It’s a useful mental model, not a measured statistic, and it’s the reason MCP gets called the USB-C port of AI integration. Communication runs on JSON-RPC 2.0 between the three participants below.
The Three Participants: Core Components of MCP Architecture
Strip away the framing differences and the current Model Context Protocol specification defines exactly three participant roles. Not four, not five.
MCP host: the AI application the user actually interacts with, Claude Desktop, Cursor, an internal agent framework. The host embeds one or more MCP clients, manages user interaction and permissions, and is what a person or system actually launches.
MCP client: the connector living inside the host, maintaining a one-to-one connection with a single MCP server. A host that needs to reach three servers runs three MCP clients, each with its own connection. Clients handle capability discovery, learning what a given server supports, either up front through an optional discovery call or as part of each request, before any tool execution happens.
MCP server: the program connecting AI assistants to external services, exposing tools to invoke, resources to read, prompts to reuse, back to whichever client connects to it. A server has no awareness of the host; it only sees the requests from the client in front of it, and it executes whatever those requests ask within the scope of its own business logic.
That’s the complete list of primary components in the client-server architecture the spec’s own documentation describes, current as of the 2026-07-28 revision. Everything else discussed below is either a capability those three participants exchange, or a mechanism they use to communicate, not a fourth or fifth participant.
Why “Context Store” Isn’t a Fourth Participant
A pattern shows up across secondary MCP guides: a fourth term gets added to the host/client/server list, most often something like “context store,” described as the piece that “manages contextual knowledge.” It’s a reasonable-sounding addition. It’s also not in the spec.
What that term is usually gesturing at is real: MCP servers, whether running in local development environments or as remote servers, do manage state, cached resource results, in-progress tool calls, and clients do track what capabilities a server has advertised. Since the 2026-07-28 revision removed protocol-level sessions, whatever state a server keeps is its own application state, which makes the case for a separate “context store” participant even weaker. Data access to any external systems a server exposes still happens through the same client-server exchange, not a separate storage layer a host queries directly. Data privacy requirements around sensitive data apply at that same exchange point, where a server decides what a given client is actually allowed to retrieve, not at some independent fourth component.
The distinction matters practically, not just pedantically. If your MCP architecture consists of a diagram including a standalone context store as a box with its own connection, you’ve drawn something the actual client-server session doesn’t support, and anyone implementing against your diagram will look for an integration point that doesn’t exist.
Participants vs. Capabilities: Where AI Tools, Data Sources, and External Services Fit
MCP Clients, Data Access, and the MCP Ecosystem
Here’s the second, more common source of disagreement, and it’s a different mistake than the context-store one. Several widely read pieces on this exact question answer with a list like “Tools, Resources, Prompts, Transports, and Handshake,” five items, and call that the components of MCP. That’s not wrong information. It’s an answer to a different question than “who are the participants.”
MCP defines three primitive capabilities, and MCP addresses each with a distinct interaction pattern rather than one generic call type. Tools are executable functions the AI can invoke to perform actions, calling an external api, writing to a system, triggering business logic, and the server executes the underlying operation when a client sends a call driven by user requests. Resources are data sources the AI can access for context or information, a document, a row from a knowledge base, a live reading from weather data, exposed read-only so retrieving relevant information doesn’t carry the same risk as invoking a tool. Prompts are reusable interaction templates the server provides, letting a client pull a pre-built structure for a common task instead of reconstructing it per request.
This is also where MCP versus RAG comparisons usually go wrong. MCP standardizes how an AI application reaches external tools and external data sources generally; retrieval augmented generation is one specific pattern used to access real time data, often backed by vector databases, that can run on top of an MCP connection rather than in competition with it. A server exposing a vector search endpoint as a Resource is doing RAG through MCP, not choosing one over the other.
None of tools, resources, or prompts are participants. They’re what gets exchanged between the participants, not who’s doing the exchanging, and each server advertises its own supported capabilities and available tools when a client asks, so a client only sees what that specific server actually offers, not a fixed, protocol-wide tool usage menu shared across the entire MCP ecosystem. Transport (STDIO or Streamable HTTP) and capability negotiation (a connection-time handshake before 2026-07-28, per-request metadata since) aren’t participants either; they’re the mechanism the exchange runs over. Both framings, “three participants” and “the capabilities plus mechanism a server exposes,” are accurate descriptions of real parts of MCP. They just answer two different questions that happen to share the same casual phrasing, “what are the components of MCP,” which is exactly why the search results for this topic disagree with each other without any of them being straightforwardly false.
If you’re asking “who’s in the room,” the answer is three: host, client, server. If you’re asking “what does a server actually offer, and how do the participants talk,” the answer runs longer: tools, resources, prompts, plus transport and capability negotiation as the connective mechanism. Precision here means answering the specific question being asked, not defaulting to whichever list is more familiar.
What Changed on July 28, 2026: Sampling Is Deprecated
Sampling used to be listed alongside tools, resources, and prompts as one of MCP’s core capabilities. It let a server ask the host’s model to generate a completion mid-task, which was useful for a server that needed the model’s help summarizing something before continuing its own work. Several guides still ranking for this topic describe it that way, as a defining, current feature of the protocol.
That changed with the July 28, 2026 specification revision, which deprecated Sampling along with two other features, Roots and Logging. Deprecated doesn’t mean removed. Sampling still works under the new spec and must stay available for at least twelve months, so the earliest it can be removed is the first revision released on or after July 28, 2027. But the specification is clear that new implementations shouldn’t adopt it and should integrate directly with LLM provider APIs instead. Any tutorial, code sample, or architecture diagram that presents Sampling as a current, recommended capability predates that revision. If you’re judging how current a guide on this topic is, checking whether it mentions Sampling’s deprecated status is a quick, concrete test.
The same revision removed the initialize handshake and protocol-level sessions. Each request now carries its own protocol version and capabilities, with an optional discovery call for clients that want a server’s capabilities up front. Method and tool names travel in HTTP headers (Mcp-Method and Mcp-Name), so infrastructure in the path can route and authorize a call without parsing its body. Requests that used to flow from server to client, such as elicitation, now use Multi Round-Trip Requests: the server returns a result asking for input, and the client retries the original call with it.
None of this changes the answer to the question this article is about. The participants are still host, client, and server, and tools, resources, and prompts are still what a server exposes. It does mean that any guide describing sampling as a defining capability, or a handshake as a core component, is describing the 2025-11-25 revision or earlier.
Transport: The Key Components of Where the Three Participants Actually Connect
Briefly, since deployment detail belongs in a full architecture walkthrough, not here: the three participants communicate over one of two transports. STDIO handles local, same-machine communication with no network overhead, standard input and output streams between processes. Streamable HTTP handles remote communication, HTTP POST for client-to-server messages with optional server-sent events for streaming, and it’s the transport MCP’s authorization specification applies to. That authorization is built on OAuth, and the 2026-07-28 revision aligned it more closely with how OAuth and OpenID Connect are deployed in practice. The older HTTP+SSE transport is now formally deprecated.
An MCP gateway doesn’t add a fourth participant either. To the clients in front of it, a gateway is a server. To the servers behind it, it’s a client. That’s how Obot MCP Gateway applies tool-level access control and audit logging without changing the protocol, and the new routing headers make that position easier to run at scale. The host side matters too: the host is where a server connection gets configured, which is why Obot Sentry reads MCP configurations in hosts like Claude Code and Cursor on developer machines. Together they’re part of Obot’s Enterprise AI Control Plane.
For the full lifecycle, deployment patterns, and worked client-server examples, see our complete guide to MCP architecture, which covers the operational side of running these three participants in production rather than just defining them.
FAQ
How many main components does MCP have?
Three participant roles: host, client, server. Sources that answer four or five are usually either adding an informal term not in the spec’s own vocabulary, or answering a related but different question, what capabilities a server exposes, rather than who the participants are.
What is an MCP host?
The AI application a user directly interacts with, such as Claude Desktop or an IDE-integrated agent. The host embeds one or more MCP clients and is the entry point for the whole system.
What is an MCP client?
The connector inside a host that maintains a one-to-one connection with a single MCP server. A host connecting to multiple servers runs a separate client instance for each one.
What is an MCP server?
The program that exposes tools, resources, and prompts to whichever client connects to it. A server has no visibility into the host; it only interacts with the requests from the client in front of it.
Is a “context store” a real MCP component?
No, not as a standalone participant. The term shows up in some secondary guides describing how servers manage state and cached context, but that happens within the client-server exchange itself, not as a fourth, independently addressable component in the specification.
Is Sampling still part of MCP?
Sampling is deprecated as of protocol version 2026-07-28, along with Roots and Logging. It still works and stays in the specification for at least twelve months, but new implementations shouldn’t adopt it. It lets a server request a completion from the host’s model mid-task. Guidance describing it as a current, active capability reflects an earlier spec revision.
What’s the difference between MCP’s components and its capabilities?
Components, host, client, server, are the participants: who is talking to whom. Capabilities, tools, resources, prompts, are what gets exchanged between them once connected. Transport and capability negotiation are how that exchange happens. Conflating these three layers is the most common source of disagreement across guides answering this question.
