Skip to main content

Introduction to MCP - What Is the Model Context Protocol

This guide gives engineers who build MCP (Model Context Protocol) servers and clients the big picture and a suggested learning path. The category is based on the 2026-07-28 specification and also covers differences from earlier revisions.

1. What This Document Covers​

  • Background and purpose
  • Participants (Host / Client / Server)
  • Server features and client features
  • Base protocol and transports
  • Extensions
  • Spec revision history
  • Governance and ecosystem
  • Reading order for this category

Background and purpose​

For an LLM application to connect to an external system (an issue tracker, a database, a SaaS product), each pairing of application and system used to need its own integration code. With M applications and N systems, that is M x N integrations.

MCP turns the connection into a common protocol. An application implements an MCP client once and can then connect to any system that exposes an MCP server. It is inspired by the Language Server Protocol (LSP), which solved the same combinatorial problem for editors and language servers.

MCP defines only the protocol for exchanging context. It does not dictate how an AI application uses an LLM or how it manages the context it receives.

Participants (Host / Client / Server)​

RoleDescriptionExamples
HostThe AI application that coordinates one or more MCP clientsClaude Code, Claude Desktop, Visual Studio Code
ClientA connector inside the host that maintains the connection to one MCP serverThe host creates one per server it connects to
ServerA program that provides context and capabilitiesA filesystem server, Sentry's MCP server

The host creates one MCP client for each server it wants to connect to, and each client has a dedicated one-to-one connection with its server.

"MCP server" refers to the program that provides context, regardless of where it runs. A server that the host launches as a child process over the stdio transport is called "local", and one exposed over Streamable HTTP is called "remote". A local server typically serves a single client, while a remote server typically serves many.

Server features and client features​

A server can expose three kinds of primitives.

PrimitiveDescriptionTypical controller
ToolsFunctions the model executes (file operations, API calls, database queries)The model
ResourcesData that serves as context (file contents, database records)The application
PromptsTemplates for users (system prompts, few-shot examples)The user

Each primitive has methods for listing (*/list), retrieval (*/get), and execution (tools/call). Clients use */list to discover what is available dynamically.

The feature a client provides is Elicitation, which lets a server ask the user for more input or confirmation. In the 2026-07-28 revision, Roots, Sampling, and Logging are deprecated and should not be adopted in new implementations.

Base protocol and transports​

MCP has two layers.

  • Data layer
    • Defines message structure and semantics based on JSON-RPC 2.0, including capability discovery, Tools / Resources / Prompts, and notifications
  • Transport layer
    • Handles connection setup, message framing, and authorization. There are two transports: stdio and Streamable HTTP

The 2026-07-28 data layer is stateless. Every request carries the protocol version and the client's capabilities in _meta, so a server can process each request on its own. A client that wants to learn a server's supported versions and capabilities up front can send server/discover, but it is not required. The initialize exchange and the Mcp-Session-Id header were removed, so any request can land on any instance behind a plain round-robin load balancer.

Extensions​

On top of the core protocol are extensions, which are opt-in modules. Examples:

  • Tasks: for long-running requests, the server returns a durable handle and the client polls for status and the result. It moved from the core to an extension in 2026-07-28
  • MCP Apps: returns interactive UI as the result of a tool
  • Skills over MCP: discovers and retrieves Agent Skills from a server. It builds on the Resources primitive

Spec revision history​

MCP uses date-based versioning. Many articles online still assume initialize and sessions, so always check which revision a piece of information is based on. The history is summarized in the table in the next section.

Governance and ecosystem​

Anthropic released MCP in November 2024. It is now an open specification, developed by Core Maintainers and working groups under the Agentic AI Foundation, part of the Linux Foundation.

  • SDK maturity is expressed through a tier system. As of 2026-07-28, TypeScript, Python, Go, and C# are Tier 1
  • The official Registry lets you publish and discover servers
  • Changes to the spec are proposed as SEPs (Specification Enhancement Proposals), and deprecations follow a policy with a minimum twelve-month window

Reading order for this category​

The intended order is spec, then implementation, authorization, security, the context problem and CLI comparison, and finally operations. See "3. Learning Roadmap" for details.

2. Spec Revision History​

RevisionHighlights
2024-11-05Initial release. stdio and HTTP+SSE transports
2025-03-26Introduced Streamable HTTP and OAuth-based authorization (HTTP+SSE deprecated)
2025-06-18Added Elicitation and reorganized authorization (MCP server as resource server)
2025-11-25Tasks (experimental), URL mode Elicitation, Client ID Metadata Documents, and more
2026-07-28Stateless core (no sessions or initialize), Multi Round-Trip Requests, Tasks moved to an extension

Besides the changes in the table, the 2026-07-28 revision includes the following.

  • Streamable HTTP requests must include the Mcp-Method and Mcp-Name headers, so gateways and WAFs can route and rate-limit without parsing JSON bodies
  • Results such as tools/list carry ttlMs and cacheScope, so clients can decide their own caching strategy
  • Authorization requires RFC 9207 iss validation, and Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents (CIMD) (it remains for authorization servers that do not support CIMD, and its earliest removal is the first revision released on or after 2027-07-28)
  • Roots, Sampling, and Logging are deprecated (they stay in the specification for at least twelve months from the 2026-07-28 release). The legacy HTTP+SSE transport was deprecated earlier; under the SEP-2596 transition rule its earliest removal is three months after that SEP reaches Final

3. Learning Roadmap​

The documents in this category are meant to be read in the following order.

4. Common Pitfalls​

Do not assume initialize and sessions from older articles​

Resources from 2025-11-25 and earlier often assume the initialize / initialized handshake and the Mcp-Session-Id header. Both are gone in 2026-07-28, and every request is self-contained. When you implement a server, avoid designs that keep per-connection state in memory between requests.

Application state is still possible without protocol state​

A stateless protocol does not stop an application from handling state. If you need it, have a tool mint an explicit handle (ID) and have the model pass it back as an argument to the next call. Because the model can see the handle, this is easier to work with than session state hidden in the transport.

An "MCP server" is not necessarily local​

An MCP server can be a local process or a remote service exposed over HTTP. Do not read "run a server" as always meaning operating a long-lived process. A stdio server is launched by the host as a child process.

Do not confuse Streamable HTTP with the legacy HTTP+SSE​

The HTTP+SSE transport from 2024-11-05 was replaced by Streamable HTTP in 2025-03-26. The old transport is deprecated, and under the SEP-2596 transition rule its earliest removal is three months after that SEP reaches Final (removal is a Core Maintainers decision, not automatic). Use Streamable HTTP for new servers.

Change notifications are opt-in and not guaranteed​

Notifications such as notifications/tools/list_changed arrive only if the client subscribed with subscriptions/listen and named the types it wants. They are also best effort and can be lost across reconnects. Clients should combine them with re-fetching based on ttlMs.

Choose between Tools, Resources, and Prompts​

Making everything a tool increases the definitions shown to the model and pressures its context. Split by purpose: operations the model executes are Tools, read-only data is Resources, and canned instructions the user picks are Prompts. The problems caused by the number and size of tool definitions are covered in The Context Bloat Problem and Mitigations.

MCP does not decide how the LLM is used​

MCP only defines how context and capabilities are exchanged. Which tools get called and how their results are handled is up to the host and the model, and tool results must be treated as untrusted input.

5. Code Examples​

These examples show the 2026-07-28 exchange as JSON-RPC messages. SDKs hide message construction, so you usually do not need to think at this level, but it helps when debugging.

Discovering capabilities (server/discover)​

Every request carries the protocol version and the client's capabilities in _meta. server/discover is an optional request for when you want to learn the server's supported versions and capabilities first.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

The response includes the supported versions (supportedVersions), the server's capabilities (capabilities), and caching hints (ttlMs, cacheScope).

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": {}
    },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": { "name": "example-server", "version": "1.0.0" }
    },
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

Listing and calling tools (tools/list, tools/call)​

tools/list returns each tool's name, description, inputSchema, and more. The model reads these definitions to decide which tool to call with which arguments.

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": { "type": "string", "description": "City name, address, or coordinates" },
            "units": { "type": "string", "enum": ["metric", "imperial", "kelvin"], "default": "metric" }
          },
          "required": ["location"]
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

To execute, call tools/call with the name from the listing in name and arguments that match inputSchema in arguments.

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

Over Streamable HTTP, the same request is sent as an HTTP POST with the following headers. A gateway can route and authorize on these headers alone.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: weather_current

Connecting a server to Claude Code​

As an example host, here are the commands that add servers to Claude Code. Register remote servers over HTTP and local servers over stdio.

# Add a remote (Streamable HTTP) server
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Add a local (stdio) server. Everything after -- is the server launch command
claude mcp add --transport stdio airtable --env AIRTABLE_API_KEY=YOUR_KEY \
  -- npx -y airtable-mcp-server

# List registered servers
claude mcp list

To share a server with your team, add --scope project and it is written to .mcp.json at the project root.

{
  "mcpServers": {
    "shared-server": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

6. Summary​

  • MCP solves the M x N integration problem between LLM apps and external systems with a common protocol. A client inside the host connects one-to-one with each server
  • Servers expose Tools / Resources / Prompts, and clients provide Elicitation. Roots, Sampling, and Logging are deprecated
  • The 2026-07-28 revision is stateless: it removes initialize and sessions and carries what each request needs in its _meta. server/discover is optional
  • Changes such as the Mcp-Method / Mcp-Name headers, ttlMs / cacheScope, and iss validation make MCP fit existing HTTP operations
  • When reading any resource, first check which revision it assumes
  • The remaining documents follow this order: spec, implementation, authorization, security, the context problem and CLI comparison, and operations

References​