Skip to content

Core MCP Concepts

Participant Role
Host The AI application the user interacts with (e.g. Claude Desktop, an IDE). Manages clients, enforces security policies and user consent, coordinates the model.
Client A component inside the host that maintains a 1:1 relationship with exactly one server.
Server A program that exposes capabilities (tools, resources, prompts) to clients. Can run locally or remotely.
flowchart LR
U[User] --> H[Host application]
H --> C1[Client 1]
H --> C2[Client 2]
H --> C3[Client 3]
C1 --> S1[Server A<br/>local process]
C2 --> S2[Server B<br/>remote service]
C3 --> S3[Server C<br/>remote service]
MCP topology: one host, many clients, one server each
Primitive Controlled by Purpose Example
Tools Model Executable actions the model can invoke (with human-in-the-loop approval) send_email, query_database
Resources Application Data/context the host application decides how to use file contents, DB schemas
Prompts User Reusable prompt templates the user explicitly selects a “summarize” slash command
Primitive Purpose
Elicitation The server requests additional input from the user via the client
Sampling Deprecated The server asks the client to run an LLM completion — servers get model access without embedding an SDK or API key
Roots Deprecated The client tells the server which filesystem boundaries (file:// URIs) it may operate within — informational guidance, not access control
  1. Data layer — JSON-RPC 2.0 messages: requests, responses, notifications; the primitives above; utilities like progress, cancellation, and pagination.
  2. Transport layer — how bytes move: stdio (local subprocess, newline-delimited messages) or Streamable HTTP (remote, supports SSE streaming).

Connection setup and capability negotiation

Section titled “Connection setup and capability negotiation”

Features are gated by capability negotiation — a server can only offer tools, resources, or prompts it has advertised. How capabilities are exchanged depends on the spec revision:

  • Legacy revisions (2025-11-25 and earlier): the connection starts with an initialize request; client and server exchange protocol version and capabilities, then the client sends notifications/initialized.
  • Current revision (2026-07-28): MCP is stateless — there is no handshake. Every request carries the protocol version, client info, and client capabilities in _meta fields, and servers advertise their capabilities via the server/discover request.
  • Tools are model-controlled, resources are application-controlled, prompts are user-controlled — this distinction is heavily tested
  • MCP messages use JSON-RPC 2.0
  • Each client has a 1:1 relationship with one server; the host runs many clients
  • Capability negotiation gates every feature, whether via the legacy initialize handshake or per-request metadata plus server/discover in the current stateless revision

📝 Check your knowledge

1. Which participant maintains a 1:1 relationship with exactly one server?
2. Who controls when a Tool is invoked?
3. Which server-side primitive is application-controlled?
4. Which client-side primitive lets a server request an LLM completion through the client?
5. What message format does MCP use at the data layer?
6. In the current (2026-07-28) spec revision, how does a client learn a server's capabilities?