List an MCP server card in the AI Catalog
The AI Catalog names an MCP server (urn:air:built2winweb.com:mcp:server) but not as an MCP server card, so a client looking for one will not find it.
Read prompt
My website built2winweb.com scored 100/100 on Good for Bots (Excellent). Good for Bots measures one thing: whether a language model can read a site and cite it.
I need you to: list this site's MCP server in an AI Catalog at /.well-known/ai-catalog.json.
The capability it only partly has is "Lists an MCP server card in its AI Catalog". It carries no points at all: a capability is recorded as a badge on the report and never touches the score. What the scanner saw: The AI Catalog names an MCP server (urn:air:built2winweb.com:mcp:server) but not as an MCP server card, so a client looking for one will not find it.
The catalog names an MCP server, but not as an MCP server card: its entry carries another
`type`, typically `application/json`, and points at the endpoint itself. Clients find MCP
servers by selecting entries whose `type` is `application/mcp-server-card+json`, so this one
is invisible to them. Publish a card for the server, point the entry at it with the card type,
and move the endpoint URL into the card's `remotes`.
An agent can only use an MCP server it has been told about, unless the site says so itself
at a predictable address. The current MCP discovery route does that with two documents: an
AI Catalog at the site's well-known address listing what the site offers agents, and a
Server Card for each MCP server, saying where to connect and over which transport.
This follows SEP-2127, the MCP Server Card extension, and the AI Catalog specification it
builds on. SEP-2127 is an Extensions Track proposal still in review, and its wire format lives
in the `experimental-ext-server-card` repository. Both are drafts and have moved during 2026,
so follow the current documents rather than older write-ups.
The catalog must:
- be served at exactly `https://built2winweb.com/.well-known/ai-catalog.json`, as
`Content-Type: application/ai-catalog+json`;
- contain `specVersion` (currently `"1.0"`) and an `entries` array;
- carry one entry per MCP server, with `type` set to `application/mcp-server-card+json`, an
`identifier` of the form `urn:air:<publisher domain>:mcp:<name>`, and exactly one of `url`
(where the card lives) or `data` (the card itself, inline).
Each card must:
- carry `$schema` set to `https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json`;
- carry a `name` in reverse-DNS form with exactly one slash, such as `com.example/weather`, a
`version` that is a real version rather than a range, and a `description` of at most 100
characters;
- list the server's endpoints in `remotes`, each with a `type` of `streamable-http` or `sse`
and the endpoint's `url`;
- when hosted, be served as `Content-Type: application/mcp-server-card+json` with
`Access-Control-Allow-Origin: *`, and preferably with `Cache-Control` and an `ETag`.
The recommended place for a hosted card is the MCP endpoint's own URL followed by
`/server-card`, so a server at `https://built2winweb.com/mcp` serves its card at `https://built2winweb.com/mcp/server-card`.
A card may equally live on another domain, such as the MCP host's own, as long as the
catalog's `url` points at it.
A minimal catalog:
```json
{
"specVersion": "1.0",
"entries": [
{
"identifier": "urn:air:built2winweb.com:mcp:server",
"type": "application/mcp-server-card+json",
"url": "https://built2winweb.com/mcp/server-card"
}
]
}
```
And the card it points at:
```json
{
"$schema": "https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json",
"name": "com.example/server",
"version": "1.0.0",
"description": "What this MCP server lets an agent do, in one line.",
"remotes": [
{ "type": "streamable-http", "url": "https://built2winweb.com/mcp" }
]
}
```
Replace the name, version, description and endpoint with this project's real ones. The scan
cannot know them, and a card describing an endpoint that does not exist sends every agent to
a dead address.
Two things to get right, because they are the common failure modes. First, the card is public
metadata: never put credentials, internal hostnames or per-user data in it, and do not list
tools, resources or prompts, which the extension deliberately leaves to the live connection.
Second, a card at `/.well-known/mcp.json` or `/.well-known/mcp/server-card.json` on its own is
not enough. Those placements come from earlier drafts; the current one discovers cards only
through the catalog, and a client following it never looks there. An existing card can stay
where it is, provided the catalog's `url` points at it.
Two places where this scan deliberately reads the specification its own way, so the result is
not a surprise. The badge needs a card an agent can connect from (a name, a description and
at least one remote endpoint), which is stricter than the schema, where `remotes` is optional,
and looser everywhere else: a missing `$schema`, a long description, the wrong media type or
missing CORS headers are recorded in the report as notes but do not withhold the badge. And
the scan reads only `/.well-known/ai-catalog.json`, never the older placements.
If this project has no remote MCP server, skip this entirely; a server that only runs locally
over stdio has nothing to list either, because cards describe remote endpoints. A catalog
listing a server that does not exist is worse than no catalog, and nothing here is lost by not
having one.
The whole report, as markdown, is at https://goodforbots.com/r/built2winweb.com.md?scan=cmuthmf43002u01p3c61a1m75. Read it first: this prompt covers one finding, and the report has everything the scan saw.
When you are done, summarise what you changed and how to check it against a running instance. Do not try to run the Good for Bots scan yourself: it only sees what is already deployed, it is rate-limited, and re-running it is the site owner's call once the change ships.