+1 capabilitybadge capabilities from 3 to 4
List an MCP server card in the AI Catalog
The AI Catalog lists an MCP server card, but the card has no name.
Read prompt
My website pixelrope.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 lists an MCP server card, but the card has no name.
The catalog lists an MCP server card, but the document at that address is not one an agent
can connect from: it is not JSON, it is an HTML page, or it lacks a name, a description or a
remote endpoint with a `streamable-http` or `sse` transport. Earlier drafts and vendor
conventions produced shapes built around `serverInfo`, `endpoint` or `mcpServers`, and a
client following the current extension reads none of them. Rewrite the card in the v1 shape
below and keep the catalog entry pointing at it.
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://pixelrope.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://pixelrope.com/mcp` serves its card at `https://pixelrope.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:pixelrope.com:mcp:server",
"type": "application/mcp-server-card+json",
"url": "https://pixelrope.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://pixelrope.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/pixelrope.com.md?scan=cmw1ukfmuw47s01pjus6yf6oi. 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.
