MCP server card and AI catalog generator

MCP server card generator

Describe your remote MCP server. Get a Server Card and an AI Catalog file that follow the current draft discovery proposal, checked against its schema rules.

Draft proposal, not part of the MCP spec

This follows SEP-2127 (“MCP Server Cards”), which is still an open proposal, and the experimental Server Card extension that tracks it. Field names and locations may change, and it isn’t part of the official MCP specification as of September 2026. Clients may not look for these files yet.

Name (reverse-DNS)

Error: Required, e.g. com.example/weather.

Version

Description0 chars

Error: Required: one clear sentence about what the server does (max 100 characters).

Display title (optional)

Website URL (optional)

Remote endpoint

Transport

Streamable HTTPSSE (older)

Endpoint URL

Use {variables} for per-user parts, e.g. https://{tenant}.example.com/mcp.

Supported protocol versions

2024-11-052025-03-262025-06-182025-11-25

Repository and icon (optional)

Repository URL

Source

Subfolder (optional)

Icon URL

MIME type (optional)

Sizes (optional)

Server Card (server-card.json)

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json",
  "name": "",
  "version": "1.0.0",
  "description": ""
}

Serve it with Content-Type: application/mcp-server-card+json. The draft recommends <your streamable HTTP URL>/server-card.

AI Catalog entry

Identifier

Format urn:air:{publisher}:{namespace}:{name}. Derived from your name; edit if your domain differs.

Catalog entry points to the card by

URLInline copy

Card URL

Error: The card URL must be a full https:// URL (add a remote endpoint, or type it).

/.well-known/ai-catalog.json

{
  "specVersion": "1.0",
  "entries": [
    {
      "identifier": "urn:air:example.com:mcp:server",
      "type": "application/mcp-server-card+json",
      "url": ""
    }
  ]
}

Serve at /.well-known/ai-catalog.json, ideally as application/ai-catalog+json.

Response headers the draft asks for (card endpoint)

Content-Type: application/mcp-server-card+json
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: Content-Type, If-None-Match
Access-Control-Expose-Headers: ETag
Cache-Control: public, max-age=3600
ETag: <any validator; answer If-None-Match with 304>

Checks against the draft schema (3 errors, 1 warning)

Failname: Required, e.g. com.example/weather.
Faildescription: Required: one clear sentence about what the server does (max 100 characters).
FailcardUrl: The card URL must be a full https:// URL (add a remote endpoint, or type it).
Warningremotes: Add at least one remote endpoint; a card without one can't tell clients where to connect.

Want AI assistants to understand your docs too? Pair this with an llms.txt file.

What a Server Card is (and isn’t yet)

A Server Card is a small JSON document that tells an AI client how to connect to your remote MCP server before it connects: name, version, description, endpoint URLs, transport, required headers and supported protocol versions. It comes from SEP-2127, which is still open, and the working group’s experimental extension repo, whose README says it’s “not an accepted or official MCP extension”. The schema URL the card must reference (static.modelcontextprotocol.io/schemas/v1/server-card.schema.json) returned 404 when we checked in September 2026. Build it if you want early discovery; expect field names to change.

How discovery works in the current draft

Your domain publishes an AI Catalog at /.well-known/ai-catalog.json. Each MCP entry has an identifier like urn:air:example.com:mcp:weather, the type application/mcp-server-card+json, and either a url or the card inline as data.
The card itself lives at any URL; the recommended spot is /server-card appended to your streamable HTTP endpoint. A .well-known location for the card was considered and not recommended.
Hosts should serve cards over HTTPS with Access-Control-Allow-Origin: *, Cache-Control: public, max-age=3600 and an ETag. The tool prints the full header set.

Rules the tool checks

From the extension’s schema.ts: name is reverse-DNS with exactly one slash (com.example/weather, 3–200 characters); version is one exact version, no ranges like ^1.2 or 1.x, and semver is recommended; description is 1–100 characters; remote URLs start with http(s):// or a {variable}; icon sizes look like 48x48 or “any”. We also flag header values that look like real secrets, and the older SSE transport, which MCP replaced with streamable HTTP in the 2025-03-26 revision.

Make your site readable to AI in other ways

A card helps agents connect to your server. For your docs and marketing pages, an llms.txt file and clear robots.txt rules (see the AI crawler checker) do more today. Our post What is llms.txt explains where each file fits.

Questions

Is there an official /.well-known/mcp.json?

No. As of September 2026 the MCP specification has no accepted discovery file. SEP-2127 (MCP Server Cards) is an open proposal, and its experimental extension is labelled 'not an accepted or official MCP extension'. Older, closed proposals suggested /.well-known/mcp/server-card.json (SEP-1649) and /.well-known/mcp (SEP-1960), and an early revision of SEP-2127 used /.well-known/mcp-server-card. Some tools still probe those paths, but the current draft uses /.well-known/ai-catalog.json instead.

Where should I host the Server Card?

The draft recommends GET <your streamable HTTP URL>/server-card, so a server at https://example.com/mcp serves its card at https://example.com/mcp/server-card, with Content-Type application/mcp-server-card+json. Any unreserved URL works as long as the AI Catalog points to it.

Can I put my API key in the card?

No. Cards are public by design and the draft says they must not include credentials or tokens. Describe the header instead: 'Authorization' with value 'Bearer {api_key}', marked required and secret. Clients prompt the user for the value. The tool flags values that look like real keys.

Does the card list my tools?

No. Server Cards only describe identity and how to connect. Tools, resources and prompts are still listed at runtime by the protocol's list operations after a client connects.