MCP Server Card Checker

What an MCP server card is

An MCP server card is a small JSON document that describes a remote MCP server before a client connects to it: its name, its version, the transport it speaks and the MCP protocol versions it supports. MCP, the Model Context Protocol, is how AI agents call tools that live outside them. The card lives at the server's own address plus /server-card, so a server at https://example.com/mcp publishes its card at https://example.com/mcp/server-card.

A client that knows only the domain finds the card through the domain's AI Catalog, a list of the AI artifacts the site offers, at /.well-known/ai-catalog.json. Each entry of the catalog gives the exact address of a card, so the card can live on another host, for example the catalog on the main domain and the server on an API subdomain.

server.json, server card, ai-catalog.json: three different files

• server.json is the entry the official MCP registry publishes about a server. The registry reads it when the server is published. Clients do not look for it on the site.
• The server card is what a client reads before it connects, at <server address>/server-card, served as application/mcp-server-card+json.
• ai-catalog.json is the table of contents of the domain. It points at the cards and at any other AI artifacts the site offers.

The card and the registry entry share their name, version, title and description. When they disagree, the report says where.

What this MCP server validator checks

• Finding the catalog from the domain. The three ways the AI Catalog text gives, in the order an agent tries them: a Link header with rel="ai-catalog", a <link rel="ai-catalog"> in the page, and the well-known address.
• The catalog. Whether it is valid AI Catalog JSON, whether each entry points at its artifact in exactly one way, whether identifiers follow the urn:air form, and whether every address it lists answers.
• The card. The fields the schema requires and their limits (a name such as com.example/weather, one exact version, a description of 100 characters or fewer), every remote endpoint, protocol versions that actually exist, and no tokens or private addresses left in it.
• How the card is served. HTTPS with TLS 1.2 or later, the CORS headers the standard lists, a browser preflight, Cache-Control, and an ETag that returns 304 when the card has not changed.
• The live server. The Streamable HTTP endpoint the card names on its own site is asked who it is, with server/discover or the earlier initialize handshake, and its answer is compared with the card: name, version and protocol versions. The standard asks clients to check a card against the live server in this way.
• Beyond the standard. The official MCP registry entry under the same name, a card left at an old address, and whether the card's name, its host and the catalog publisher point at the same domain. These lines are notes and never count as faults.

This is not a replacement for MCP Inspector. The Inspector connects to MCP servers from your own machine and calls their tools. This check looks at what an agent sees before it connects: whether the server can be found, whether its card is valid and served correctly, and whether the card tells the truth about the server.

Looking for /.well-known/mcp/server-card.json?

An earlier draft put the card at a well-known address such as /.well-known/mcp/server-card.json or /.well-known/mcp.json. The final standard does not use those locations. The card goes at the server address plus /server-card, and the domain lists it in /.well-known/ai-catalog.json. If a card is still at an old address, the report names it and says where to move it. A scanner that only looks at the old address reports a correct setup as missing.

How to read the result

Every check prints one line. A red FAIL breaks a MUST of the standard, a yellow WARN departs from a SHOULD, and a blue INFO is a note: something optional, or something no standard requires. Under each fault is a FIX line with the change that clears it, and the data below the report gives the section of the standard behind each finding. There is no grade.

For site owners who find this MCP server checker in their logs: it identifies itself as packet.guru-server-card-checker/1.0, runs only when someone asks it to check a site, and does not sign its requests. It reads the documents described above with GET and OPTIONS, sends a POST only to an MCP endpoint on the same site as the card, and stops at a fixed number of requests per check.

The last line counts the cards found, the MUST failures and the SHOULD deviations. When no card is found, it says no server card found, so an empty check never looks like a clean one. To check how an agent signs its requests, use the Agent Verifier.