MCP server cards and discovery
Sources checked 2026-09-15
A server card describes an MCP endpoint for clients that support the relevant discovery convention. The card, the live endpoint and the client's protocol support must agree.
As of September 2026 the server card lives in two places that have not converged. Deployed cards, turva.dev's among them, commonly sit at /.well-known/mcp/server-card.json. The proposal behind the card, SEP-2127, now develops as an experimental MCP extension, and its draft reserves a different default, the MCP endpoint URL followed by /server-card. The draft does not recommend a /.well-known path for the card itself, and site-level discovery instead sits in a catalog: the experimental Server Card document keeps an AI Catalog at /.well-known/ai-catalog.json, while ARD v0.91 names /.well-known/ard.json. The convention is still moving, so a client that checks only one location may miss a card that exists at the other.
An MCP server card is a small JSON file that describes a site's Model Context Protocol server so a client can find it and learn what it offers. The Model Context Protocol itself is a standard way for agents to use external tools and data. A server implements the protocol and exposes a set of tools, and the card is how that server announces itself before any connection is made.
On this page
What the card states
A useful card states the server name, the endpoint and the transport, in a shape a client can parse without guessing. Many published cards, including turva.dev's, also list the tools the server offers. The newer draft leaves that list to the live MCP connection instead, since a tools list answer from the running server cannot go stale the way a static list in a card can.
Where discovery can fail
Finding a card is not the same as confirming the server works. A card can exist at a stale path, point to an endpoint that has moved, or name a transport the client does not support, and a client that stops at the card being found has not checked any of that. The card, the live endpoint and the client's own protocol support all have to agree before a connection succeeds, and only the connection attempt itself confirms that they do.
How it fits with other discovery files
A server card sits in the same family as other well-known manifests a client looks for, such as an API catalog, an OpenAPI description and OAuth discovery. Each one removes a guess. The card answers what tools a server might expose, the API catalog answers what endpoints exist, and OAuth discovery answers how to authenticate. turva.dev publishes a server card that points to a read-only MCP server, which exposes the same agent-readiness data that the site shows to people, so a client can query the data directly rather than scraping a page.
Practical steps
Publish the card at the deployed convention your target clients actually check, and confirm it with a live connection attempt rather than a directory listing. Where a client supports the newer draft location, publish there too rather than choosing one over the other, since the two conventions have not converged. The card is a low cost step for a site that wants to expose a capability to agents, and it only becomes useful once a client can reach and use the endpoint it names.
Frequently asked
What is an MCP server card?
An MCP server card is a small JSON file that describes a site's Model Context Protocol server, its endpoint and its transport, so a client can attempt a connection without a human wiring it up first. The current draft leaves the tool list to the live connection rather than to the card.
Why publish an MCP server card?
Without a card or a registry listing, a client has no reliable way to discover that the server exists or what it offers, so the capability stays hidden even when it is live. Publishing the card is a low cost way to make the server discoverable, though discovery alone does not confirm the endpoint works.
Where does an MCP server card live?
Deployed cards commonly sit at /.well-known/mcp/server-card.json, and turva.dev serves one there. The current experimental draft reserves a different default, the MCP endpoint URL followed by /server-card, so a client may need to check both locations until the convention settles.