MCP Servers Explained (for API Teams)

An MCP server is a program that offers your API's capabilities to AI agents in a form they can call directly, using the Model Context Protocol — an open standard for connecting AI applications to external systems. For an API team, that one sentence carries a strategic decision: whether agents integrate with you by reading your documentation and writing code, or by connecting to a server you operate and calling the operations you chose to expose.

This article covers what the protocol actually specifies, what a server exposes, what shipping one changes about your documentation (less than you might hope), and the discovery layer — the manifest and registry listing that determine whether agents can find your server at all. That last part is where the data gets interesting: registry listings are common across the APIs Discry scans, while the discoverable manifest is the emptiest signal in the entire discovery battery.

What MCP actually is

The Model Context Protocol (MCP) was introduced and open-sourced by Anthropic in November 2024. It has since grown into a broadly supported open standard: AI assistants, coding tools like Visual Studio Code and Cursor, and a widening set of clients all speak it, and its registry infrastructure is backed by contributors including Anthropic, GitHub, and Microsoft.

The protocol follows a client-server architecture. An AI application (the host — Claude, ChatGPT, an IDE, your customer's custom agent) creates an MCP client for each server it connects to. The MCP server is your side of the connection: a program that provides context and capabilities over a JSON-RPC 2.0 exchange. Servers run in one of two modes — locally on the user's machine over stdio (typically installed as a package), or remotely over Streamable HTTP, operated by you like any other service endpoint.

The USB-C analogy from the protocol's own docs is the right mental model: one standardized port instead of a custom integration per AI application. Before MCP, connecting an assistant to your API meant a bespoke plugin per platform. With it, you build one server and every MCP client can use it.

What an MCP server exposes

The specification defines three core primitives a server can offer:

• Tools — executable functions the agent can invoke: create a charge, query a database, send a message. This is tool use with your API on the other end, and it is the primitive most API teams ship first.
• Resources — data the agent can read for context: file contents, records, reference material. Where tools act, resources inform.
• Prompts — reusable interaction templates the server provides, useful for packaging a multi-step workflow the agent would otherwise have to reconstruct.

A useful way to hear this as an API team: tools are your operations, resources are your reference data, and prompts are your integration guides — reshaped into a form an agent consumes natively instead of parsing out of HTML.

The design decision that matters most is scope. A good MCP server is a curated set of task-shaped capabilities ("issue a refund," "look up a customer's subscription status"), each with a description an agent can act on. An endpoint-for-endpoint mirror of your OpenAPI spec makes a poor server: agents choose among tools by reading their descriptions, and forty near-identical CRUD tools are harder to choose between than eight workflow-shaped ones.

Your docs still matter

Shipping an MCP server changes how connected agents integrate with you. It changes much less for everyone else, and "everyone else" is currently most of your agent traffic.

Consider who is actually reading your API surface today. Coding agents — Cursor, Claude Code, Copilot — scaffold integrations by fetching your public docs and writing code against them, whether or not your MCP server exists. An agent that hasn't installed your server has exactly one way to learn your API: the documentation surface. And before any agent connects to your server, something — a developer, an agent, an aggregator — has to discover that your API is worth connecting to, which is a docs-and-discovery problem, not a protocol problem.

So an MCP server complements your documentation; the two serve the same agent at different moments. Your llms.txt and AGENTS.md serve the agent deciding whether and how to build on you. Your server serves the agent that has already connected. Teams that ship a server and let the docs surface decay have optimized the second moment while losing the first.

One more continuity: your tool descriptions are documentation. The same writing discipline that makes endpoint descriptions comprehensible to a model — task-oriented, example-bearing, explicit about errors — is what makes an agent pick the right tool and call it correctly. Shipping a server does not exempt you from writing for machine readers; it gives you a second surface to write well.

The discovery layer: manifest and registry

A server nobody can find contributes nothing. MCP's discovery layer has two parts, and Discry checks both as discovery signals.

The manifest. Publishing an MCP manifest at /.well-known/mcp.json on your own domain gives clients and crawlers a standard place to learn that your MCP server exists and how to reach it — the same fixed-location convention that makes robots.txt and security.txt findable without prior knowledge. Discry's MCP manifest check fetches that path and verifies it holds valid JSON; a malformed file earns partial credit, absence fails. Across the APIs we scan, 5% pass. That makes it the least-shipped signal in Discry's discovery battery — which is the polite way of saying almost nobody has claimed this ground yet. Resend, Netlify, and Pinecone are among the few that serve one today. For a team deciding where an afternoon of agent-readiness work goes, a well-known manifest is rare enough to be a differentiator on its own.

The registry. An MCP registry is a public directory of servers that clients and aggregators query. The official MCP Registry — currently in preview — stores standardized server.json metadata (where the server lives, how to run it, what it does), verifies namespaces through DNS, and exposes a REST API that downstream marketplaces and hosts pull from. Community registries operate alongside it. Discry's MCP registry check probes public registry search for a listing matching the API's name; 76% of the APIs we scan pass.

Read those two numbers together and the shape of the ecosystem appears: registry listings are widespread, often because community members published a server for an API before its owner did, while the owner-controlled signal on your own domain — the manifest — is almost entirely unclaimed. Stripe, GitHub, and Slack all show a public registry listing and no /.well-known/mcp.json at the time of our scan. A registry entry says a server exists somewhere; the manifest is your domain vouching for which one is yours.

A boundary worth stating plainly: these are discoverability checks. Discry verifies that the manifest is present and valid and that a registry listing exists — it does not run your MCP server or test its behavior. The methodology page describes exactly what each check fetches.

A realistic minimal path to shipping one

The minimum credible version of this project is smaller than most teams assume:

1. Pick three to five workflows, not your whole API. Choose the tasks agents most plausibly perform against your product and shape one tool per task. You can widen later; you can't easily recover an agent's attention from a forty-tool sprawl.
2. Build on an official SDK. The protocol ships SDKs across major languages that handle the JSON-RPC plumbing, capability negotiation, and transports. That leaves your team's effort where it belongs: defining the tools and writing their descriptions.
3. Choose a transport deliberately. A remote server over Streamable HTTP is one deployment you operate and version — usually the right call for a hosted API. A stdio package pushes install friction onto every user but needs no hosting.
4. Write tool descriptions like the documentation they are. Task-first names, concrete parameter examples, explicit failure modes. This is the comprehension work, and it transfers directly from good endpoint docs.
5. Publish the discovery layer. Add your server.json to the official MCP Registry under your DNS-verified namespace, and serve a valid manifest at /.well-known/mcp.json. This is minutes of work and, at 5% adoption, currently the cheapest way to stand out in a discovery scan.
6. Keep the surfaces in agreement. When the API changes, the server, the docs, and the manifest all need the update. Drift between them is the failure mode agents hit hardest, because an agent can't tell which surface is stale.

Ranked against your other agent-readiness work, this lands behind the fundamentals for most APIs. An OpenAPI spec, a focused llms.txt, and an AGENTS.md serve every agent that reads your public surface; the MCP server serves the subset that connects. The prioritized checklist walks that ordering in full. But if the fundamentals are in place and a competitor's launch has someone asking "where's our MCP server?", the path above is the honest scope of the answer — and the manifest and registry steps are the part a discovery scan can verify the day you ship.

What grade does an AI agent give your API? Discry your API — free — 60 seconds, no signup.