Before your agent can use a Model Context Protocol server, it has to shake hands with it. That handshake — the initialize round-trip — is the only way to learn even trivial facts: what the server is called, what version it runs, which transports it speaks. Want to build a registry of ten thousand servers? You open ten thousand connections. Want a browser to auto-configure a connection to a server it just discovered? It has to negotiate the full protocol first and ask questions later.

That is the friction SEP-2127 — "MCP Server Cards" — sets out to remove. It lands alongside the same 2026 push toward scale that gave us the stateless MCP core: both are about making the protocol survive ordinary HTTP infrastructure instead of assuming a long-lived session. The proposal, authored by MCP lead David Soria Parra, gives every HTTP-based server a small public JSON file at a fixed address: /.well-known/mcp-server-card. Fetch it with a plain GET, no handshake, and you learn who the server is and how to reach it.

What the card actually says#

A Server Card is deliberately boring. The required fields are name (in reverse-DNS form, like com.acme.search), version (semver), and description. Optional ones round out the storefront: title, websiteUrl, repository, icons. The load-bearing part is the remotes array — one entry per way to connect:

{
  "type": "streamable-http",
  "url": "https://mcp.acme.com/v1",
  "supportedProtocolVersions": ["2025-06-18"],
  "headers": [
    { "name": "X-API-Key", "isRequired": true, "isSecret": true }
  ]
}

From that, a client knows the transport, the endpoint, which protocol versions it can negotiate, and — crucially — which auth headers it must supply before it wastes a connection attempt. HTTPS is mandatory, the content type is application/json, and CORS is wide open (Access-Control-Allow-Origin: *), because the card is a read-only advisory with nothing secret in it. Servers sharing an origin get namespaced paths: /.well-known/mcp-server-card/{server-name}.

The interesting part is the omission#

Here is the decision worth stopping on. A Server Card does not list the server's tools. Or its resources. Or its prompts. The one thing you might most want from "discovery" — what can this thing do? — is exactly what the card refuses to tell you.

Discovery here means "here is who I am and how to reach me," not "here is what I can do."

The spec is blunt about why: "the primitives a server exposes can vary by authenticated user, session, configuration, feature flags, deployment state, and more." A server might expose a delete_customer tool to an admin token and nothing to an anonymous one. It might feature-flag a capability on for 5% of sessions. A static file pinned to a .well-known path cannot honestly represent something that changes per request — so it doesn't try.

This is not a small design detail; it's the whole philosophy. The earlier of the two proposals that fed into SEP-2127, SEP-1649, did imagine a richer card that included tool listings, good for humans browsing a catalog. The other, SEP-1960, was a thin manifest focused on endpoints and auth. When they converged, the merged design sided with thin-and-static over rich-and-dynamic — on purpose.

Why "no tools" is a feature, not a gap#

The temptation, the moment you can read a manifest, is to trust it. To let a client decide "this server has the refund tool, so I'll route refund requests here" without ever connecting. Or worse, to treat the advertised capability list as an access-control surface: if it's not in the card, the user can't reach it.

Both are bugs waiting to happen, because the advertised scope and the runtime scope are different objects. It's the same category error that powers the confused-deputy problem in MCP: trusting a piece of static, forgeable-looking metadata to stand in for a decision that only an authenticated session can actually make. A card that promised tools would invite clients to build logic on a promise the server never has to keep for any given session. By refusing to enumerate primitives, Server Cards keep the contract honest: the card is for reaching a server and negotiating transport and auth; the live connection remains the only source of truth about capabilities. Capability negotiation stays where it can actually be authorized — inside an authenticated session — instead of leaking into a cacheable file a CDN might serve to anyone.

That distinction matters more as the ecosystem scales. There are now roughly nineteen thousand servers indexed on public registries; the case for learning a server's identity without a full handshake is obvious. But identity is not authority, and a name is not a permission. Server Cards draw that line precisely: they make servers findable and reachable at web scale while conceding that what a server will do for you can only be settled once you've proven who you are.

What to do about it now#

SEP-2127 is a proposal, not yet part of the core specification, and it sits alongside the existing server.json registry format rather than replacing it. But the direction is set, and it's cheap to get ahead of:

The quiet lesson of Server Cards is one the whole agent stack keeps relearning: it is fine to make systems easy to find. Just don't confuse the sign on the door with the room behind it.