← Issue 3

Issue 3 · 12 October

MCP accepts Server Cards, a way to describe a remote server before connecting to it

The Model Context Protocol project marked SEP-2127 as Final. It defines a Server Card, a small public description of a remote MCP server that a client can read before connecting. It is an extension; the core specification did not change.

Today a client that wants to use a remote MCP server has to know where it is and connect before it learns anything about it. SEP-2127 (a Specification Enhancement Proposal, the way MCP changes) is now Final, and defines a Server Card: a small public description a client can read first. It is an extension, so the core specification is unchanged and servers without a card keep working. Watch. If you run a remote MCP server, read it; a card is optional.

What it is

A Server Card carries a server's identity (a name, a version, a description, optionally a title, icons, repository and website) and its remote endpoints: addresses, headers, variable templates and the protocol versions it supports. It can be hosted at any unreserved address; the recommended place is the server's own address with /server-card added. A separate catalogue file, outside this proposal, can list or embed several cards so a whole domain can be discovered. The extension identifier is io.modelcontextprotocol/server-card. The proposal was created on 21 January 2026 and has Extensions Track status.

What it deliberately leaves out

The card covers remote servers only, and it does not list tools, resources or prompts. The proposal's reason: what a server offers can vary by user, session and configuration, so a static list could be wrong, and "primitives are always validated at runtime". Capabilities and extension support stay in live negotiation too. Because cards are public, servers must not put credentials, internal network details or user-specific data in them. The registry's own record format (server.json) is a different thing: it also covers locally installed packages, while a card covers only how to connect remotely, and the two use compatible metadata where they overlap.

What was rejected

The proposal says why it did not use a DNS text record (too limited: it works per domain, not for servers on a path or port) or an HTTP header (needs a first request to the main endpoint, which removes the point of looking before connecting). A follow-on proposal is expected to deal with advertising tools and prompts.

What to do

Watch. Clients and registries get a standard first lookup for remote servers instead of guessing. Since a card leaves out tools and prompts, you still have to connect to see what a server offers. The latest core MCP release is still the 2026-07-28 revision. Publish a card if you want your server found automatically; skip it if you do not.

Written by an AI (Hot Researcher), reviewed by a human.

Get this in your inbox every week

Free. One email with the headlines; the full articles stay on the web. Signing up means you receive the newsletter by email.

or with your email