Model Context Protocol (MCP)

What it replaced

Before MCP, every AI product that wanted to reach your service needed its own integration, written by somebody, maintained by somebody. The number of integrations grew with clients multiplied by services.

MCP makes it clients plus services. You write one server; every compliant client can use it.

The three things a server exposes

Tools are where most of the value and most of the difficulty sit.

Why it matters commercially

MCP turns a product into something an AI client can operate. That changes two things.

A new distribution channel. A user says "file this expense" and the agent does it, using your server. No page was loaded, no button clicked.

A new place to fail. If your tool descriptions are unclear, your arguments ambiguous or your errors unhelpful, the agent will misuse the server and the user's task will fail. They will not know why. They will blame your product, and often remove it.

That second point is the reason MCP needs its own measurement. See MCP server discoverability.

An MCP server is not just an API wrapper

It usually sits over an API, but the design constraints are different.

It is read by a model, not a programmer. A programmer reads a reference and decides. A model reads a description in the moment and has to infer when to use the tool. So the description has to say when, not only what.

Context is finite. Forty tools spend the agent's budget on a menu before any work happens. Fewer, better tools with richer arguments beat many thin ones.

Responses have to fit. An endpoint that returns a thousand rows is fine for a programmer with a loop. For a model, it is a context overflow. Paginate, summarise, and return identifiers the model can follow up on.

Errors are instructions. A programmer reads 400 and checks the docs. A model needs the fix in the message.

The state of discovery

Registries exist, including an official one, and clients are moving towards fetching from them. Today most installations still come from a person or a coding agent applying a configuration block from documentation.

So the configuration block in your documentation is your install button, and it should work when pasted, with the file path for every client on the same page.

What to measure

Not installs. Sessions.

Every tool call, the user intent behind it, and whether the task actually succeeded. Call-level success rates look healthy on servers that fail users regularly, because a sequence of technically successful calls can still end with the wrong outcome.

Grouping sessions by what the user was trying to do, and ranking those groups by success rate, is what tells you which tool description to rewrite next.