What is MCP? A plain-English guide to the Model Context Protocol

MCP is the Model Context Protocol, and its own documentation defines it as an open-source standard for connecting AI applications to external systems. In practice it means an assistant such as Claude or ChatGPT can reach your files, your database or an API through one common interface, rather than each app needing a bespoke integration for each service. It began at Anthropic in November 2024 and now sits with the Agentic AI Foundation under the Linux Foundation, and the current specification revision is 2026-07-28.

#What problem does MCP actually solve?

Before a standard existed, every pairing of an AI app and an outside system was its own integration. Ten apps and ten services meant a hundred separate pieces of glue, each with its own authentication, its own idea of what a "tool" is, and its own failure modes.

The protocol's documentation reaches for a hardware comparison: MCP is meant to be to AI applications what a USB-C port is to electronic devices, a standard way to plug things together. Anthropic's original announcement, published on 25 November 2024, put the goal as letting developers build secure, two-way connections between their data sources and AI-powered tools.

The practical payoff is build once, integrate everywhere. A server you write for your own database works in any host that speaks MCP, and a host that speaks MCP gets access to every server anyone has published without writing per-service code.

#How does MCP work?

MCP follows a client-server architecture with three named participants. The distinction between them is worth getting right, because the words get used loosely elsewhere.

Participant	What it is	Example
MCP host	The AI application that coordinates and manages one or multiple MCP clients	Claude Code, Claude Desktop, Visual Studio Code
MCP client	A component that maintains a connection to one MCP server and obtains context from it for the host	The client object VS Code creates per server
MCP server	A program that provides context to MCP clients	A filesystem server, a database server, the Sentry server

The host creates one client for each server it connects to, so a host talking to three servers holds three dedicated connections. A server is called local or remote depending on where it runs and which transport it uses, but the documentation is explicit that "MCP server" means the program that serves context regardless of where that is.

Underneath, the protocol has two layers. The data layer is a JSON-RPC 2.0 exchange protocol that defines the message structure, the capability and version discovery, and the core primitives. The transport layer defines the channels those messages travel over, along with message framing and authorization.

#What can a server expose?

Three primitives, and the split between them is the part most worth learning.

Primitive	What it is	Typical examples
Tools	Executable functions the AI application can invoke to perform actions	File operations, API calls, database queries
Resources	Data sources that provide contextual information	File contents, database records, API responses
Prompts	Reusable templates that help structure interactions with a model	System prompts, few-shot examples

Each type has methods for discovery and retrieval, and tools additionally have tools/call for execution. Clients find what is available with the */list methods, which is what makes a server's offering dynamic rather than fixed at configuration time.

Clients can expose a primitive of their own. Elicitation lets a server request additional information from the user, through elicitation/create, which is how a server asks for a missing detail or confirms an action before doing it.

The announcement for 2026-07-28 lists three deprecations: Roots, Sampling and Logging. It says they "still work, and they'll keep working for at least twelve months." The architecture documentation describes two of them as client primitives. Sampling, which let a server ask the client's AI application for a model completion, is deprecated, and the documentation tells new implementations to integrate directly with provider APIs instead. Logging is deprecated too, in favour of writing to stderr on the stdio transport or using OpenTelemetry. If you are reading an older MCP tutorial, this is the most likely thing in it to be out of date.

#What do the two transports do?

Transport	How it works	When it is used
Stdio	Standard input and output streams between processes on the same machine	A local server, with no network overhead
Streamable HTTP	HTTP POST for client-to-server messages, with optional Server-Sent Events for streaming	A remote server, with bearer tokens, API keys or custom headers, and OAuth recommended for tokens

A local stdio server typically serves one client. A remote Streamable HTTP server typically serves many.

#What changed in the 2026-07-28 specification?

This revision, announced on 28 July 2026, is a major one: maintainer David Soria Parra is quoted in the announcement calling it "MCP's most important since remote MCP first launched over a year ago". The project describes the core change as MCP transforming from a bidirectional stateful protocol into a request and response stateless protocol. Several of the other changes follow from that one.

Change	What it means in practice
Stateless core	Every request carries the protocol version and the capabilities relevant to it in a _meta field, so a server infers nothing from earlier requests
Discovery via server/discover	Servers advertise supported versions and capabilities through a mandatory request that clients may send before any other. Clients are not obliged to call it
Multi Round-Trip Requests	Server-to-client requests, such as elicitation, are redesigned to use the MRTR pattern
Header-based routing	Method and tool names travel in the Mcp-Method and Mcp-Name HTTP headers, so gateways can route and authorize on headers directly
Cacheable list results	List responses carry cache hints and a deterministic order, so clients can cache tool catalogues
Authorization hardening	RFC 9207 issuer validation, and a shift from Dynamic Client Registration to Client ID Metadata Documents
Formal extensions framework	Tasks joins other extensions such as MCP Apps and Enterprise Managed Authorization

Change notifications also became opt-in. A client that wants them opens a long-lived subscriptions/listen stream naming the notification types it wants, and the server delivers matching notifications on that stream. The documentation also notes notifications are best effort, so a client should still poll to keep results fresh.

The extensions framework is where the protocol now grows without the core growing. The Tasks extension, for instance, lets a server return a durable handle for a long-running request so a client can poll for status and collect the result later.

#Which agents and apps speak MCP?

The protocol's own documentation names Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam among the clients that support it, and that list is the point of the exercise: a server written once works across them. Our MCP platform hub tracks the current facts on the standard itself, and if you want to see servers wired into a self-hosted agent rather than a vendor app, running MCP servers with OpenClaw walks through that side.

MCP is also one of four extension points that get confused with each other in the Claude Code world specifically. If you are deciding between them rather than learning the protocol, our breakdown of skills, subagents, plugins and MCP servers separates them.

#Does a host support all of MCP?

No, and assuming otherwise is the usual cause of a connector that works in one app and not another. Anthropic's connector documentation says plainly that Claude implements a subset of the MCP specification, with its own callback URL and its own size and timeout limits.

Reading that page for what it concretely commits to:

Area	What Claude's documentation states
Surfaces	Claude connects to your server from claude.ai, Claude Desktop, Claude mobile, Cowork and Claude Code, all on the same connector infrastructure
Transport	Use Streamable HTTP. The legacy HTTP and SSE transport is still supported and is being deprecated in favour of it
Authentication	OAuth 2.0 per user, a static credential an organization Owner enters once, or no authentication
Authorization specs followed	The 2025-03-26, 2025-06-18 and 2025-11-25 authorization specifications
Not yet supported	Resource subscriptions, sampling, and advanced or draft capabilities
Tool result size	About 150,000 characters on claude.ai and Desktop; 25,000 tokens in Claude Code, configurable with MAX_MCP_OUTPUT_TOKENS
Tool call timeout	240 seconds per call on the hosted surfaces; configurable in Claude Code with MCP_TOOL_TIMEOUT

Mobile being on that list matters if you are deciding where a connector needs to work, because it means a remote server reaches the phone app on the same infrastructure as the web and desktop ones.

Two of those rows are worth holding together. The specification deprecated sampling at 2026-07-28, and Claude's documentation lists sampling among the features it does not yet support, so a server design that leans on a server asking the host for a completion is on thin ground from both directions.

Note also that Claude's documentation names authorization specification revisions from 2025 rather than 2026-07-28. Build against what the host you are targeting documents, not against the newest revision of the protocol, and test against the real client.

There are two ways a server reaches people in Claude. As a custom connector, a user or an organization Owner adds it by entering its URL, with no review by Anthropic. From the directory, Anthropic lists it after a review. Both run on the same infrastructure.

#Who runs MCP now?

Anthropic released MCP on 25 November 2024, open-sourcing the specification and SDKs, adding local MCP server support to the Claude desktop apps, and publishing a repository of pre-built servers. Block and Apollo were named as early adopters, with Zed, Replit, Codeium and Sourcegraph among the development tool companies working with it.

On 9 December 2025 Anthropic announced it was donating the protocol to the Agentic AI Foundation, described in that announcement as a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The stated reasoning was the Linux Foundation's track record in facilitating open collaboration and maintaining vendor neutrality.

On governance, the announcement said the project's maintainers would continue to prioritise community input and transparent decision-making. It is worth reading that as the commitment it is rather than as a description of a structure: the announcement does not name the individuals or bodies that make specification decisions, nor set out the process by which the specification is changed. If you need to know who decides what goes into a revision, that is a question to take to the project's own contributing and governance material rather than to the donation announcement.

#How do you start building?

Through an official SDK. The project lists ten, sorted into tiers by feature completeness, protocol support and maintenance commitment.

Tier	SDKs
Tier 1	TypeScript, Python, C#, Go, Rust, Ruby
Tier 2	Java
Tier 3	Swift, PHP, Kotlin

All of them can create servers that expose tools, resources and prompts, build clients that connect to any server, use the local and remote transports, and do it with type safety. The tier tells you how much to expect in maintenance and protocol coverage, so a Tier 3 SDK is a different proposition from TypeScript or Python for production work.

Beyond the SDKs, the project's scope covers the specification itself, the MCP Inspector for development and debugging, and a repository of reference server implementations. Starting from a reference server is usually faster than starting from the specification.

#What we could not confirm

We left out any claim about how many custom connectors a particular Claude plan allows. The connector documentation we read does not state a per-plan connector limit, and we would rather omit the number than carry forward one we could not re-verify today.

We did not open the deeper pages behind several items above, including the extensions overview, the Tasks extension, the server and client concept pages, the caching and subscription specification pages, and the SDK tier definitions. Where this article describes them it describes only what the architecture overview, the SDK index and the 2026-07-28 announcement say about them.

The 2026-07-28 announcement refers to a previous November 2025 release without giving it a version string, so this article does not name the immediately preceding specification revision.