Guide

What is MCP (Model Context Protocol): a plain-English guide

Published 27 September 2026

MCP is a standard way for an AI application to reach outside itself: to call a function, read a record, or pull in a saved prompt, without hand building an integration for that pair of systems. Most explanations in circulation are a revision behind, and they get two structural things wrong: they describe a connection handshake that no longer exists, and they list client features that have been deprecated. This guide describes the protocol at revision 2026-07-28.

What MCP is for

The specification calls MCP an open protocol for seamless integration between LLM applications and external data sources and tools. The homepage puts it as an image: "Think of MCP like a USB-C port for AI applications."

Three roles do the work, exchanging JSON-RPC 2.0 messages.

  • Hosts are the LLM applications that initiate connections.
  • Clients are connectors inside the host application with a 1:1 relationship to a particular server.
  • Servers provide context and capabilities.

What a server offers: three primitives

A server can expose three kinds of thing: tools, resources and prompts. Tools are model-controlled, resources are application-driven, and prompts are user-controlled.

Primitive What it is Who controls it Core operations
Tools Executable functions the AI application can invoke to perform actions Model tools/list, tools/call
Resources Data sources that provide contextual information Application resources/list, resources/read, subscriptions/listen
Prompts Reusable templates that structure interactions User prompts/list, prompts/get

The control column matters. Tools are model-controlled: the spec says the model can discover and invoke them automatically from its contextual understanding and the user's prompts. Prompts are user-controlled, requiring explicit invocation, and resources are application-driven. Only a tool fires on the model's own initiative.

Tools have two error paths, and confusing them is a common bug.

Error path How it is reported What it means
Protocol error A standard JSON-RPC error The tool does not exist or the request was malformed
Tool execution error Inside a normal result with isError: true A business failure, with actionable feedback the model can use to self-correct and retry

Collapse a business failure into a protocol error and the model never gets to fix its call.

What the client side actually is now

The client side now offers servers exactly one feature, elicitation. Sampling and logging are deprecated as of protocol version 2026-07-28, and roots survives only as a legacy server-to-client interaction type.

Here is where most current guides are wrong. They say clients offer sampling, roots and elicitation back to servers. The spec landing page now lists exactly one: "Clients may offer the following features to servers: Elicitation: Server-initiated requests for additional information from users."

Sampling is deprecated as of protocol version 2026-07-28, per the docs architecture page, which adds that new implementations should integrate directly with LLM provider APIs. Logging is deprecated too, and roots survives only as one of the legacy server-to-client interaction types, now delivered as an input request embedded inside a result. If a tutorial has you implement a sampling callback in your client, it was written against an older revision.

There is no initialize handshake

Almost every description says the client and server negotiate capabilities with an initialize request, then talk over a stateful session. That is now the legacy model. The architecture page calls MCP a stateless protocol, every request self-contained. The versioning page is blunter: "There is no negotiation handshake. Every request carries its protocol version, and the server accepts or rejects each request independently." It reserves Legacy for revisions that establish a session with an initialize handshake, 2025-11-25 and earlier. A server now advertises what it can do through a server/discover request.

The spec spells out the consequence for tool authors: "MCP has no protocol-level session, so a server cannot rely on implicit per-connection state to relate one tool call to the next." If your tool needs state across calls, return an explicit handle from a creation tool and take it as an argument on the calls that follow.

Two transports: stdio and Streamable HTTP

MCP has two transports. With stdio, the client launches the server as a subprocess and talks to it over stdin and stdout; with Streamable HTTP, the server runs independently and every client message is a new POST to a single endpoint.

Protocol semantics are identical on every transport. A transport only defines how messages are framed and delivered and how cancellation and termination are signaled. A guide that sends you to basic/transports for stdio details predates this revision: that URL is now an overview, with stdio and Streamable HTTP on child pages.

With stdio, the client launches the MCP server as a subprocess and they exchange newline-delimited JSON-RPC over stdin and stdout. One rule catches everyone once: the server must not write anything to stdout that is not a valid MCP message, so a stray print statement breaks the channel. Logging goes to stderr.

With Streamable HTTP, the server runs independently over a single endpoint path that supports POST. Every client message is a new POST carrying an MCP-Protocol-Version header, and the reply is either a JSON object or an SSE stream. The docs put it plainly: "Local MCP servers that use the STDIO transport typically serve a single MCP client, whereas remote MCP servers that use the Streamable HTTP transport will typically serve many MCP clients."

This revision broke Streamable HTTP the most. Its page carries a callout: "Revision 2026-07-28 changed the behavior of Streamable HTTP. Clients must ensure they handle backwards compatibility correctly. Changes included: Removal of the GET stream endpoint. Removal of protocol-level sessions." Session identifier headers and DELETE termination went too, Last-Event-ID resumability is gone, and servers can no longer send independent JSON-RPC requests on a stream. Long-lived server push now needs an explicit subscriptions/listen request.

Why a protocol beats one-off integrations

Without a shared protocol, every AI application needs a custom adapter for every system it touches; with one, each side implements its half once. The MCP homepage names Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam among the applications that support it.

A protocol also carries safety expectations a private integration would have to invent. Hosts must obtain explicit user consent before invoking any tool, and the tools page says: "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations." Clients must treat tool annotations as untrusted unless they come from trusted servers: a server's description of its own behaviour is an input, not a guarantee.

Where to go deeper

Microsoft's MCP for Beginners is an open curriculum under the MIT License, numbered in modules rather than lessons: 13 of them, 00 through 12, expanded into 60 rows. The README states: "This curriculum is aligned with MCP Specification 2025-11-25 (the latest stable release)." It does flag the 2026-07-28 release candidate, including the move to a stateless transport layer and the deprecation of Roots, Sampling and Logging. Use it for concepts and code, the specification for current message shapes.

Where this fits if you use Bespoke Prompting

Bespoke Prompting's MCP Tool build type turns a plain-language description into a fixed eight-section spec, and three of its behaviours track the details above. Its doctrine is one callable tool, one job, so it derives a tool count of one and flags any request that implies more than one. It flags a stdio plan meeting a multi-user scenario, because that needs streamable HTTP rather than a client-launched subprocess. And it floors three mandatory error codes into every spec, the practical form of the tool-execution-error rule: a failure the model can read and act on.

Sources

Suggested internal links