MCP Servers Explained: What the Model Context Protocol Actually Standardises

Every explanation of MCP opens with the same line: it is USB-C for AI. That analogy is not marketing invention, it comes from the specification itself, and it is a good one. But it stops exactly where the useful questions begin. What does a server actually hand over? Who talks to whom? And what did the latest revision quietly remove from the tutorials you are about to copy?

What MCP is, in the specification's own words

The official documentation defines MCP as an open-source standard for connecting AI applications to external systems. Using it, applications like Claude or ChatGPT can connect to data sources, tools and workflows, which lets them access information and perform tasks.

Then comes the analogy everyone repeats: think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.

The part of that comparison worth holding on to is what it excludes. A connector standard says nothing about the devices. The docs make the same restriction explicit: MCP focuses solely on the protocol for context exchange, and it does not dictate how AI applications use LLMs or manage the provided context. If you were hoping MCP would tell you how to build your agent, it will not. It tells you how to plug things into it.

Host, client, server: three roles that are constantly confused

This is where most architecture discussions go wrong, because in everyday speech "the MCP client" and "the app" sound like the same thing. In the specification they are not:

MCP Host. The AI application that coordinates and manages one or multiple MCP clients. Claude Desktop and Visual Studio Code are hosts.

MCP Client. A component that maintains a connection to an MCP server and obtains context from it for the host to use. It is a connection object inside the host, not a piece of software your users install.

MCP Server. A program that provides context to MCP clients.

The relationship between the last two is strictly one to one. The host creates one MCP client for each MCP server, and each client maintains a dedicated connection with its corresponding server. Connect VS Code to a Sentry server and a filesystem server and the runtime instantiates two separate client objects. There is no shared multiplexed channel to reason about, which simplifies debugging considerably.

The three things a server can expose, and why the distinction matters

The primitives are the heart of MCP, and choosing the wrong one is the most common design error in a first server. The specification defines three that servers expose:

Tools. Executable functions that AI applications can invoke to perform actions, for example file operations, API calls or database queries. Tools do something.

Resources. Data sources that provide contextual information, for example file contents, database records or API responses. Resources are read.

Prompts. Reusable templates that help structure interactions with language models, for example system prompts or few-shot examples.

The documentation's own example is the clearest test of whether you have picked correctly. For a server exposing a database, it suggests tools for querying the database, a resource containing the schema, and a prompt with few-shot examples for interacting with the tools. Same database, three different primitives, each answering a different question. If you find yourself exposing your schema as a tool, that is the signal you have conflated "data the model should read" with "an action the model can take".

Each primitive type has discovery methods, and clients use the list methods to find what is available before using anything. That is what makes listings dynamic rather than baked into the client at build time.

Two transports, and the security question that follows

MCP has two layers: a data layer defining the JSON-RPC based protocol, and a transport layer defining the communication mechanisms. The protocol uses JSON-RPC 2.0, and the same message format travels across every transport, which is why the transport choice does not change how you write your handlers.

Stdio transport. Uses standard input and output streams for direct process communication between local processes on the same machine, providing optimal performance with no network overhead.

Streamable HTTP transport. Uses HTTP POST for client-to-server messages with optional Server-Sent Events for streaming. This one enables remote server communication and supports standard HTTP authentication including bearer tokens, API keys and custom headers, and the specification recommends using OAuth to obtain authentication tokens.

Note what that implies, because it is rarely spelled out. A stdio server has no authentication of its own: it is a process the host launched, running with whatever permissions that process has. That is perfectly reasonable for a filesystem server on your own laptop, and it is the wrong model the moment the same code is exposed over HTTP. The docs also observe that local stdio servers typically serve a single client, while remote HTTP servers typically serve many, which is a load and isolation consideration as much as a networking one.

What the 2026-07-28 revision deprecated

This is the section that will save you from copying an outdated tutorial, because two client-side features that appear in most existing MCP material are no longer the recommended path.

Sampling is deprecated as of protocol version 2026-07-28. It let servers request language model completions from the client's AI application, which was attractive because a server author could stay model-independent and avoid bundling an LLM SDK. The documentation now directs new implementations to integrate directly with LLM provider APIs instead.

Logging is deprecated in the same revision, with new implementations told to log to stderr on the stdio transport, or to use OpenTelemetry.

What remains on the client side is elicitation, which allows servers to request additional information from users. It is the mechanism for asking a question or confirming an action mid-operation, and it is the one to reach for when a server needs input it cannot infer.

The same revision also makes the statelessness explicit: every request carries the protocol version and the capabilities relevant to that request in its meta field, so the server can process each request on its own. Servers advertise their supported versions and capabilities through a mandatory discovery request that clients may send before any other. Practically, that means an MCP server does not need to remember who it is talking to between calls, which makes horizontal scaling of a remote server far less painful than it would otherwise be.

Why this matters beyond the protocol

The strategic point is not the JSON. It is that MCP is an open protocol supported across a wide range of clients and servers, with AI assistants like Claude and ChatGPT and development tools like Visual Studio Code and Cursor all supporting it, which as the docs put it makes it easy to build once and integrate everywhere.

For a business, that changes the shape of the integration question. Exposing your internal systems through one MCP server is not a bet on a single vendor's assistant. It is the same work paying off across every host that speaks the protocol, present and future. That is a materially different risk profile from writing a bespoke plugin for one product, and it is the main reason MCP deserves a place in an integration roadmap rather than a proof of concept folder.

Frequently Asked Questions

What is the Model Context Protocol in one sentence?

The specification defines it as an open-source standard for connecting AI applications to external systems. Its own documentation offers the analogy people repeat everywhere: think of MCP like a USB-C port for AI applications, because just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems. The useful part of the analogy is that it is about the connector, not the device: MCP focuses solely on the protocol for context exchange and does not dictate how AI applications use LLMs or manage the provided context.

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

They are three distinct roles and confusing them is the most common source of architectural mistakes. The specification defines the MCP Host as the AI application that coordinates and manages one or multiple MCP clients, the MCP Client as a component that maintains a connection to an MCP server and obtains context from it for the host to use, and the MCP Server as a program that provides context to MCP clients. The relationship is one client per server: the host creates one MCP client for each MCP server, and each client maintains a dedicated connection.

What can an MCP server actually expose?

Three primitives, and they are not interchangeable. Tools are executable functions that AI applications can invoke to perform actions, such as file operations, API calls or database queries. Resources are data sources that provide contextual information, such as file contents, database records or API responses. Prompts are reusable templates that help structure interactions with language models. Each primitive has discovery methods, and clients use the list methods to find what is available before using it, which is what makes the listings dynamic.

Is a local MCP server different from a remote one?

Only in transport, not in nature. The specification is explicit that MCP server refers to the program that serves context data regardless of where it runs. What differs is the transport: stdio uses standard input and output streams for direct process communication between local processes on the same machine, with no network overhead, while Streamable HTTP uses HTTP POST with optional Server-Sent Events and enables remote communication. The docs note that local stdio servers typically serve a single client, whereas remote HTTP servers typically serve many.

Does MCP handle authentication?

It is handled at the transport layer, and only the HTTP transport needs it. The specification states that the Streamable HTTP transport supports standard HTTP authentication methods including bearer tokens, API keys and custom headers, and that MCP recommends using OAuth to obtain authentication tokens. A stdio server inherits the permissions of the process that launched it, which is a security property worth stating out loud before you expose one.

What changed in the 2026-07-28 revision?

Two things worth knowing before you copy an older tutorial. Sampling, which allowed servers to request language model completions from the client, is deprecated as of protocol version 2026-07-28, and the documentation tells new implementations to integrate directly with LLM provider APIs instead. Logging is deprecated in the same revision, with new implementations directed to write to stderr on stdio or use OpenTelemetry. The protocol is also stateless: every request carries the protocol version and relevant capabilities in its meta field, so the server can process each request on its own.

The definition of MCP, the USB-C analogy, the statement that MCP focuses solely on the protocol for context exchange, the definitions of host, client and server, the one-client-per-server relationship, the definitions of tools, resources and prompts, the two transports and their properties, the OAuth recommendation, the deprecation of sampling and logging as of protocol version 2026-07-28, and the statelessness of the protocol are all taken from the official Model Context Protocol documentation, checked at the time of writing. The protocol is revised, so verify against the revision you are targeting.

ZAX Support for MCP and AI Integration

Our team builds MCP servers that expose internal systems to AI applications, and integrates them into existing products.

Audit and scoping. A free 30-minute AI audit establishes which of your systems are worth exposing, which primitive fits each one, and whether stdio or HTTP is the right transport for your constraints.

Development and integration. Server design, primitive modelling, authentication on the HTTP transport, and integration testing against real hosts.