How does MCP work? Architecture, tools and transports explained

On the "What is MCP?" page you can read why the protocol exists: it replaces bespoke per-app-per-tool integrations with a single standard. Here we go one layer deeper: how the architecture fits together, which building blocks an MCP server offers, how the connection works technically and which spec versions exist. Technical enough for your developers, readable enough for an IT manager who needs to assess what is happening on the network.

How is the MCP architecture structured?

MCP has three roles you need to keep apart. The host is the AI application itself: Claude Desktop, VS Code, ChatGPT or your own agent. The host is the coordinator and the security layer: it manages connections, enforces user consent and decides what goes to the language model. Inside that host, one client runs per connected server — a protocol connection with a strict 1:1 relationship to exactly one server. Finally, the MCP server is the (local or remote) program that delivers the actual functionality: reading files, querying a CRM, creating a booking.

Role	What is it?	Responsible for
Host	The AI application (Claude Desktop, VS Code, ChatGPT)	Security, consent, LLM integration, aggregating context
Client	Protocol connection inside the host, 1:1 with a single server	Capability negotiation, message traffic, isolation between servers
Server	Program that offers capabilities	Providing tools, resources and prompts

Schematically, with two connected servers:

Host (e.g. Claude Desktop)
 ├── Client 1  ──stdio──────────▶  MCP server A (local, e.g. files)
 └── Client 2  ──Streamable HTTP─▶  MCP server B (remote, e.g. CRM)

For decision-makers, one design principle from the official architecture specification matters most: the full conversation history stays with the host. An MCP server never sees the whole conversation, only receives the context needed for its own invocation, and cannot look into other connected servers. Each client thus forms a security boundary. That keeps the exposure per server limited and assessable — although real risks remain, such as prompt injection via tool results, covered in more depth on our security page. A second principle: servers are meant to be extremely easy to build, because the host carries the orchestration complexity. That explains why a working server fits in a dozen lines of Python, as we show in our build guide.

Which building blocks does an MCP server offer?

A server offers its capabilities via three primitives, each with a different "owner":

Primitive	Who controls its use?	What is it?
Tools	The model	Executable functions with a JSON Schema for input and output, e.g. "create GitHub issue" or "query database". Since spec 2025-06-18 with structured output validated against an outputSchema.
Resources	The application (host)	Read-only data with a URI: files, database records, documents the host can add to the model context. Supports change notifications.
Prompts	The user	Predefined prompt templates that the user explicitly triggers — visible as slash commands in clients like Claude Code and Gemini CLI.

The distinction is not cosmetic. Tools being model-controlled means the language model itself decides to invoke a function (with the user's approval) — which is precisely why the host sets consent rules per tool. Resources, by contrast, are passive: the host decides which data goes along as context, and the model cannot browse through them on its own. And prompts sit entirely with the user. So anyone assessing an MCP server for risk looks primarily at the tools: that is where an AI model can actually perform actions.

Besides these three server primitives, there is traffic in the other direction. The most important active client primitive is elicitation (since spec 2025-06-18): a server can ask the user for additional input mid-operation via a schema-based form, and since 2025-11-25 even via a URL — useful for a payment or login flow. Three older mechanisms — sampling (server asks the client's model for a completion), roots (client communicates file-system boundaries) and logging — are formally deprecated as of spec revision 2026-07-28, with direct LLM APIs, tool parameters/configuration and stderr/OpenTelemetry as the recommended replacements. You will still encounter them in older tutorials and servers, but don't build new implementations on top of them.

How does the connection work: stdio or Streamable HTTP?

The specification (revision 2025-11-25) defines two standard transports; all messages are UTF-8 JSON-RPC.

stdio is the transport for local use. The client launches the server as a subprocess on the same machine and communication runs over stdin and stdout, line by line. No network is involved — relevant for compliance: with a stdio server, nothing leaves the laptop or server it runs on via the protocol itself. The spec says clients should support stdio whenever possible; it is the dominant model for desktop use such as file access and git. One classic pitfall for builders: stdout is reserved exclusively for protocol messages, so a stray print() to stdout breaks the server. Log lines belong on stderr.

Streamable HTTP is the transport for remote servers, introduced in spec revision 2025-03-26. The server exposes a single endpoint (for example https://example.com/mcp). The client POSTs each JSON-RPC message to that endpoint; the server responds with a plain JSON response or opens a text/event-stream to stream multiple messages. Connections are resumable: events carry IDs, and a client that loses the connection reconnects with Last-Event-ID, after which the server redelivers missed messages. The spec also imposes security requirements: Origin validation against DNS rebinding (403 on an invalid origin), localhost servers binding to 127.0.0.1, and authenticated connections. Rule of thumb: stdio for local and personal use, Streamable HTTP as soon as something needs to be remote, shared or hosted.

So is SSE deprecated or not?

In practice you can see the transition at vendors: Atlassian, for example, is only keeping its old /v1/sse endpoint alive until 30 June 2026. And the trend continues: in spec revision 2026-07-28, even the need for long-lived SSE streams for server-to-client requests disappears; those will run via a request/retry pattern (InputRequiredResult), moving the protocol further towards plain stateless HTTP. For anyone managing infrastructure, that is good news: no more sticky sessions or shared session stores behind the load balancer.

How does authentication work for remote servers?

Remote MCP servers use OAuth 2.1, where the MCP server acts as a resource server and the MCP client as an OAuth client. The mandatory flow is Authorization Code with PKCE. The server publishes which authorization servers it trusts via Protected Resource Metadata (RFC 9728), and clients must use Resource Indicators (RFC 8707): the token is thereby bound to the specific server it was issued for, so a malicious server cannot reuse it elsewhere. Revision 2025-11-25 added discovery via OpenID Connect and Client ID Metadata Documents as the recommended registration mechanism; 2026-07-28 tightens this further with, among other things, RFC 9207 issuer validation. The good news for builders: frameworks and gateways increasingly take this off your plate. How to set this up as an organisation is covered in the build guide and on the security page.

Which spec versions exist?

MCP spec versions are dates, not version numbers. This is the state of play as of July 2026, per the official changelogs on modelcontextprotocol.io:

Revision	Status	Key changes
2024-11-05	Superseded	First release: tools/resources/prompts, stdio and the old HTTP+SSE transport
2025-03-26	Superseded	Streamable HTTP replaces HTTP+SSE; OAuth 2.1 authorization framework; tool annotations
2025-06-18	Widely deployed	Structured tool output, elicitation, MCP servers as OAuth resource servers, RFC 8707 mandatory
2025-11-25	Current stable	OIDC discovery, Client ID Metadata Documents, tasks (experimental), URL elicitation, icons
2026-07-28	Release candidate	Largest revision ever: stateless core, extensions framework (incl. MCP Apps), auth hardening, formal deprecation policy; final at the end of July 2026

New since the 2026 cycle is a formal deprecation policy: a feature moves through the stages Active → Deprecated → Removed, with a minimum of 12 months between deprecation and removal. For businesses this means predictability: if you run a server on the stable 2025-11-25 revision today, you know that deprecated components (such as sampling, roots and logging) will keep working for at least a year after the deprecation becomes formal. Which version a client and server use together is negotiated when the connection is established, via capability negotiation — this lets the protocol evolve without breaking older implementations. How laws and regulations tie into this is covered on MCP and EU regulation.

Further reading

Frequently asked questions

What is the difference between an MCP host, client and server?

The host is the AI application itself (such as Claude Desktop or VS Code), the client is the protocol connection inside that host with a strict 1:1 relationship to a single server, and the server is the program that offers tools, resources and prompts. The host enforces security and keeps the full conversation to itself — servers never see it.

What are tools, resources and prompts in MCP?

Tools are executable functions that the AI model itself can invoke, resources are read-only data sources that the application adds to the context, and prompts are ready-made templates that the user explicitly triggers, for example as a slash command.

Which transports does MCP support?

Two: stdio for local servers (the client launches the server as a subprocess) and Streamable HTTP for remote servers (a single HTTP endpoint, with optional streaming via SSE). The old separate HTTP+SSE transport has been deprecated since March 2025.

Is SSE deprecated in MCP?

Only the old standalone HTTP+SSE transport from 2024 is deprecated. SSE as a technique is alive and well: Streamable HTTP uses server-sent events internally as an optional streaming mechanism.

How does authentication work for remote MCP servers?

Via OAuth 2.1 with the mandatory Authorization Code + PKCE flow. The MCP server acts as a resource server and clients must use Resource Indicators (RFC 8707), so that a token is only valid for the server it was issued for.

Which versions of the MCP specification exist?

Spec versions are dates, not version numbers: 2024-11-05 (first release), 2025-03-26 (Streamable HTTP, OAuth), 2025-06-18 (elicitation, structured output), 2025-11-25 (current stable version) and 2026-07-28 (release candidate, final at the end of July 2026).

Why are sampling, roots and logging being deprecated?

The 2026-07-28 spec revision marks these three client primitives as Deprecated, with a minimum transition period of 12 months. The recommended replacements are direct LLM provider APIs (for sampling), tool parameters or configuration (for roots) and stderr or OpenTelemetry (for logging). So don't build new servers on top of them.

Can an MCP server read my entire conversation?

No. According to the official architecture specification, the full conversation history stays with the host. Servers only receive the context needed for their own invocation and cannot look into other connected servers either.

Last updated: 2026-07-06