Skip to main content

What Is MCP?

Short answer

MCP stands for Model Context Protocol. It's an open standard that connects AI applications to external tools, data and prompts: an MCP server publishes what it offers, and an MCP client inside the AI app finds those tools and uses them over JSON-RPC messages. Local servers run over stdio and remote servers run over Streamable HTTP. The 2026-07-28 revision removed the connection handshake, so every request now carries its own protocol version and capabilities.

Tested withMCP spec 2026-07-28Checked 20 Oct 2026

By Tony LewisHow we test these guides

The problem MCP solves​

Without a shared protocol, every AI app needs its own integration with every service it uses. MCP gives both sides one standard way to connect. The official introduction describes it as a USB-C port for AI applications: just as USB-C standardizes how devices connect, MCP standardizes how AI applications connect to external systems.

What an app can reach through MCP falls into three groups: data sources such as local files and databases, tools such as search engines and calculators, and workflows such as specialized prompts.

Hosts, clients and servers​

MCP has three roles. The names matter because the spec uses them precisely.

RoleWhat it isExamples from the spec
HostThe AI application. It coordinates one or more clientsClaude Desktop, Claude Code, Visual Studio Code
ClientA component the host creates to keep one connection to one serverOne client per server
ServerA program that provides tools, resources and prompts to clientsA filesystem server, the Sentry server

The host creates one client for each server it connects to, and each client holds a dedicated connection to its server. A server can run on your machine or on someone else's infrastructure. The architecture overview calls the first kind local and the second remote. A local server usually serves one client, and a remote server usually serves many.

Each client in the diagram has its own connection, and the host decides which client to use for each tool call.

Server features: tools, resources and prompts​

A server can offer three kinds of features. Each one answers a different question: who decides when it's used?

FeatureWho decides when it's usedDiscovery and useWhat it's for
ToolsThe model, based on the conversationtools/list to find them, tools/call to run oneActions and lookups, such as creating a record or checking the weather
ResourcesThe host app, which decides what context to includeresources/list and resources/read, addressed by URIData the model can read, such as a file or a database schema
PromptsThe user, who picks one, often as a slash commandprompts/list and prompts/getReusable message templates with arguments

Each tool has a name, a description and an input schema. The model reads the description to decide when to call the tool and fills in the arguments from the schema. The spec also says that for trust and safety there SHOULD always be a human in the loop who can deny tool invocations, so a good host shows the user what it's about to run.

Client features: elicitation, and what is deprecated​

Clients also offer features that a server can use.

FeatureStatus in 2026-07-28What it does
ElicitationActiveThe server asks the user for input through elicitation/create, in form mode or URL mode
SamplingDeprecatedThe server asks the host's AI model for a completion
RootsDeprecatedThe client provides a list of root directories to the server
LoggingDeprecatedThe server sends log messages to the client

Elicitation has two modes. Form mode collects structured data. URL mode sends the user to an external URL for sensitive steps, such as signing in, so the data doesn't pass through the client. The spec says servers MUST NOT use form mode to request passwords, API keys, access tokens or payment credentials.

The 2026-07-28 changelog deprecates Roots, Sampling and Logging. The spec says new implementations should not add them. Its suggested replacements are to pass directories through tool parameters or resource URIs, call model provider APIs directly, and log to stderr on stdio.

Transports​

A transport carries the messages between a client and a server. The protocol meaning is the same on every transport.

stdioStreamable HTTP
Where the server runsOn the same machine. The client starts it as a subprocessAnywhere reachable over HTTP, usually remote
How messages travelNewline-delimited JSON-RPC on the process's stdin and stdoutEach message is an HTTP POST to one endpoint
RepliesWritten to stdoutA single JSON response, or a Server-Sent Events stream
CredentialsRead from the environment. The authorization spec doesn't applyAuthorization follows the spec, and OAuth is recommended for getting tokens

On stdio, the server must not write anything to stdout that isn't a valid MCP message. It can write logs to stderr. Streamable HTTP servers must validate the Origin header, and when they run locally they should bind to 127.0.0.1 rather than all interfaces.

The older HTTP+SSE transport is deprecated. It was replaced by Streamable HTTP in protocol version 2025-03-26, and the 2026-07-28 changelog moves it to the Deprecated state. New servers should use Streamable HTTP.

What changed in the 2026-07-28 revision​

The changelog lists the changes. The main ones are:

  • The protocol is stateless. The initialize handshake and the notifications/initialized message are gone. Each request carries its protocol version and client capabilities in _meta.
  • Servers implement server/discover. A client can call it to learn a server's supported versions, capabilities and identity. It is optional for the client.
  • No protocol-level sessions. The Mcp-Session-Id header is removed from Streamable HTTP, and list requests no longer change per connection.
  • Change notifications use subscriptions/listen. The client opens one long-lived request and names the change types it wants. This replaces the old GET stream and resources/subscribe.
  • Server-to-client requests are embedded in results. Elicitation requests now come back as an InputRequiredResult and are answered when the client retries the original request.
  • Results carry a resultType. It is "complete" for ordinary results, and clients must treat a missing value as "complete".

Clients and servers that predate this revision still use the older handshake. The transports spec says each side detects the other's era and falls back when it needs to.

A worked example: one tool call​

The architecture overview walks through a tool call. The host asks the server for its tools with tools/list before the model runs. When the model chooses a tool, the host sends tools/call to the server that owns it. This is that request, trimmed from the overview to drop the client identity field:

{
  "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/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

The server runs the tool and returns its output in a result with resultType set to "complete":

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"
      }
    ]
  }
}

The host then adds that content to the conversation, and the model reads it in its next turn. The model never talks to the server itself. It only sees the host's messages.

Common problems​

"MCP replaces the APIs behind my tools." It doesn't. MCP defines how a host and a server exchange messages, and the spec says it focuses solely on that protocol. A server still does its work through whatever sits behind it, such as an API or a database.

"The model calls the server directly." The host does. The architecture overview says the AI application intercepts the model's tool call, routes it to the right server, and returns the result to the model.

"A connected server can run tools without asking." The spec says there SHOULD always be a human in the loop who can deny tool invocations. Whether your app asks each time depends on the app's settings.

"SSE is the way to connect to a remote server." HTTP+SSE is deprecated. Use Streamable HTTP for remote servers.

FAQ​

What does MCP stand for?

In AI, MCP stands for Model Context Protocol. It is an open standard for connecting AI apps such as Claude, ChatGPT and Cursor to external tools, data and prompts.

What is an MCP server?

An MCP server is a program that offers tools, resources and prompts to AI apps over the Model Context Protocol. It can run on your computer and talk over stdio, or run remotely and talk over Streamable HTTP. The spec gives a filesystem server and the Sentry server as examples.

Is MCP an API?

No. MCP is a protocol that defines how an AI app and a server exchange messages. The server still does its work through whatever it connects to, which is often an API.

Which AI apps support MCP?

The official introduction lists Claude, ChatGPT, Visual Studio Code and Cursor among the apps that support MCP, and says many others do too. Support differs from app to app, so check the setup guide for your app.

What is the difference between tools, resources and prompts?

Tools are actions or lookups that the model chooses to run. Resources are data the host can read and include as context. Prompts are templates that the user picks, and they supply structured messages and instructions for the model.

Where to go next​

Each section of the library has a guide to start with: