Summary

Server Card discovery is currently specified as a static document served from a .well-known path (/.well-known/mcp/server-card). This issue argues we should seriously consider not using .well-known at all for the single-server case, and instead let ai-catalog.json (or temporarily mcp/catalog.json) point to a (non-.well-known) URI containing the Server Card.

This is largely inspired by @darrelmiller's points here.

What's specified today

SEP-2127 currently puts the card at a .well-known URI (seps/2127-mcp-server-cards.md#L257-L274, PR #2127):

Servers using HTTP-based transports SHOULD provide their server card at:

    /.well-known/mcp/server-card

…and schema.ts documents the same (schema.ts#L13-L14):

 * A static metadata document describing a remote MCP server, suitable for
 * publishing at a `.well-known/mcp/server-card` URI for pre-connection discovery.

The argument

The key point, borrowing from @darrelmiller:

The use of .well-known for discovering applications like MCP Servers and A2A agents that are hosted on some origin is a misuse of .well-known, because applications are not "site-wide metadata".

AI Catalog/MCP Catalog is responsible for initial discovery. So there is no value in using the .well-known standard for placing the final Server Card; an MCP client only needs to be aware of the Catalog's .well-known URI and the Server Card URI can live anywhere.

Proposed resolution

@SamMorrowDrums and I are thinking some spec wording roughly like so:

In the course of Discovery, after an MCP Client identifies a Server Card URL from an AI Catalog or MCP Catalog, MCP Clients SHOULD set Content-Type to `application/mcp-server-card+json` when performing a GET request to the Server Card's URL.

MCP Servers MAY host their Server Card at `GET <streamable http url>/server-card`, which we reserve for this purpose, though any unreserved URI is valid. MCP Servers SHOULD respect Content-Type `application/mcp-server-card+json` wherever they choose to host it.

Alternative guidance considered: GET directly on <streamable http url>. Choosing not to recommend this just to avoid overloading that endpoint that is already used for establishing the SSE connection, but it would technically be spec-compliant (as written above) to put it there as well.