An MCP server exposes tools and data to an AI assistant through the Model Context Protocol — a standard for how a model discovers what it can do and then does it, without the integration being hand-written for each pair.
The point is discovery. A model connected to an MCP server can ask what tools exist, read their schemas, and call them, rather than needing a developer to wire each endpoint in advance.
What a server provides
| Primitive | Is | Example |
|---|---|---|
| Tool | Something the model can call | "look up this profile" |
| Resource | Something the model can read | a document, a dataset |
| Prompt | A reusable template | "summarise this account's trend" |
A server can offer any combination. Most data products start with tools.
A REST API is not automatically an MCP server
The endpoints may be the same underneath, but three things have to be added:
- Machine-readable tool descriptions. Not documentation for a human — a schema the model reads at connection time, with each parameter's meaning.
- Honest failure semantics. A model retries differently from a human. An error that says "handle must include the instance" produces a corrected call; a generic 400 produces a guess.
- Explicit absence. A field that comes back
nullneeds to say why in a form the model can use, or the model will infer zero. This is the same requirement as in a unified schema, with a less forgiving consumer.
Discovery is the distribution channel
MCP servers are listed in registries, and that listing is how a developer who never searched for your product ends up using it. For a data API this is a genuinely different acquisition path from search — we wrote up what publishing to the registries involved.
The adjacent file
llms.txt does a related job for plain web content — see llms.txt. MCP is for calling things; llms.txt is for reading them. A data product usually wants both, and ours are generated from the same source as the site rather than maintained by hand.