What an MCP server actually is, for people shipping products

Most explanations of the Model Context Protocol start with "USB-C for AI". That analogy tells you the protocol is about connectors and nothing else, which is not enough to decide whether to build one.

Here is the version for someone who has an API and is wondering whether to wrap it.

What the protocol solves

Before MCP, connecting a model to your service meant writing an integration per client. Claude Desktop had one plugin format, an IDE had another, your own agent had a third. Every one of them needed to know your endpoints, your auth, and what your arguments meant. That is N clients times M services worth of glue.

MCP, announced and open-sourced by Anthropic in November 2024, replaces the glue with a description. Your server publishes a list of things it can do, in a schema the client can read. The client hands that list to the model. The model picks one and the client calls it. Nobody wrote an integration for your specific service.

That is the whole idea. The protocol itself is JSON-RPC 2.0 over one of two transports, and it is deliberately small.

The pieces

A server can expose three things:

In practice, most servers ship tools and nothing else. Tools are where the value is: a named function, a JSON Schema for its arguments, a description the model reads to decide when to call it.

The description matters more than developers expect. It is not documentation for a human who will read it once; it is the only thing standing between the model and calling your function at the wrong moment. "Search the catalogue" is worse than "Find tools by plain-language query. Returns up to 20 matches with name, tagline, pricing and category." The second one tells a model what it will get back, which is what it needs to decide whether calling is worth a turn.

There is one client-side primitive left in the spec overview: elicitation, where a server asks the user for more information mid-flow.

What changed recently, and why it matters if you read an old tutorial

The spec is versioned by date rather than semver. The current revision is 2026-07-28; the one before it was 2025-11-25.

The 2026-07-28 revision is not a minor cleanup. From the release post: MCP "is transforming from a bidirectional stateful protocol into a request/response stateless protocol." Concretely:

• The initialize handshake and the Mcp-Session-Id header are gone. Every request now carries the protocol version and client capabilities in _meta, and a new server/discover call replaces the up-front handshake.
• Servers no longer initiate JSON-RPC requests back at the client. Where a server used to ask the client something mid-call, it now returns an input_required result and the client retries with the answer attached — the Multi Round-Trip Requests pattern.
• Sampling and roots are deprecated. So is the logging capability. ping and logging/setLevel were removed outright.

This is worth knowing because almost every MCP explainer written before mid-2026 leads with "tools, resources, prompts, plus sampling, roots and elicitation on the client side", and describes a stateful session. That framing is now out of date. If you are following a tutorial, check its date.

Deprecated is not removed: the spec commits to a twelve-month minimum window, so sampling and roots cannot disappear before a revision released on or after 2027-07-28.

Transports: two, and one of them is on its way out

stdio — the client launches your server as a subprocess and talks to it over newline-delimited messages on stdin and stdout. This is the right choice for anything that runs on the user's machine and touches local state: a filesystem server, a database client, a git wrapper.

Streamable HTTP — each message is an HTTP POST to a single endpoint; the reply is either a JSON object or a request-scoped SSE stream. This is what you want for a hosted service, because there is nothing to install and you can deploy on your own schedule.

The older HTTP+SSE transport, with its separate endpoints for posting and streaming, has been deprecated since the 2025-03-26 revision. If you are choosing today, choose Streamable HTTP. Note also that stream resumability was removed in 2026-07-28 — a broken stream is retried as a new request, not resumed with Last-Event-ID.

Authorization, briefly

Authorization is optional and applies to HTTP transports only. For stdio, the guidance is to take credentials from the environment instead.

When you do need it, the model is OAuth 2.1: your MCP server is a resource server, the client is an OAuth client. Two requirements are worth knowing before you start:

• Servers must implement Protected Resource Metadata (RFC 9728), and clients must use it to discover the authorization server. This is how a client that has never seen your server figures out where to send a user to log in.
• Clients must send the resource parameter (RFC 8707) on authorization and token requests, whether or not your authorization server understands it.

One correction to the common narrative: Dynamic Client Registration (RFC 7591) is now deprecated, downgraded to MAY and kept only for authorization servers that cannot do better. The replacement is OAuth Client ID Metadata Documents, where the client identifies itself with an HTTPS URL. Most MCP auth writeups still lead with DCR.

Should you build one?

The useful question is not "does MCP matter" but "is there something an agent would want to do with my product that it currently cannot".

Reasonable yes:

• Your product has state a model would benefit from reading — a project, a dataset, a queue, a catalogue.
• Your product has an action worth taking that is currently a form. Filing, submitting, deploying, querying.
• Your users are already working inside an agent when they would want your product.

Reasonable no:

• Your API is a single endpoint that a model can call directly with fetch. An MCP server that wraps one GET is ceremony.
• Your product is entirely visual. A model cannot use a canvas.
• You do not have an API yet. MCP is a description layer over something that already works; it is not a shortcut past building the thing.

If you do build one, the scope discipline that matters most is not exposing everything. A server with forty tools makes the model's job harder, not easier — it has to read all forty descriptions to pick one. Six well-named tools that cover the common paths beats complete coverage of your REST surface.

What ours looks like

We run one, and it is a fair example of the shape. Six tools, Streamable HTTP, reads open to anyone with no key and no account:

search_tools, get_tool and list_categories cover the catalogue. check_submission_readiness audits a URL and returns the listing it would produce. submit_tool opens a draft. get_my_submissions reports status.

The split we care about: an agent can search, audit and open a draft. It cannot publish, choose a launch date, or pay for anything. Those need a person, on purpose — an agent that could publish unattended would turn any directory into a spam target inside a week.

Connecting is one claude mcp add --transport http away, and the API and MCP page has the exact command, the config-file version for other clients, and the full tool table. The same data is available as a REST API if you would rather not deal with the protocol at all — which is a perfectly reasonable position, and one more reason to think of MCP as a second front door rather than a replacement for the first. If you want to see what is already listed in this space, the developer tools category is the nearest neighbourhood.

Where to find servers

There is an official MCP Registry at registry.modelcontextprotocol.io, announced in September 2025 and still in preview. It holds metadata only — a server.json pointing at an npm, PyPI or Docker package, or at a remote URL — with reverse-DNS namespaces verified through GitHub, DNS or an HTTP challenge.

It is explicitly not meant to be consumed directly by host applications; the intent is that marketplaces and clients build on top of it. Which is roughly the same relationship a tool directory has to a search engine, and about as good a signal as any that this ecosystem is at the stage where the indexes are being built.