MCP Server Cards: What Agent Auto-Discovery Changes
MCP Server Cards are structured metadata documents, published at /.well-known/mcp-server-card, that let an agent learn a server’s name, version, description and connection details before it opens a single MCP session. Proposed under SEP-2127, they replace “connect first, ask questions later” with a plain HTTPS GET. For an AI architect, that turns tool discovery from a manual integration step into something an agent can do on its own, which is exactly the part worth designing for before it happens by accident.
What Problem Are MCP Server Cards Actually Solving?
MCP Server Cards solve the cost of finding out what a server does before you’ve committed to talking to it.
Under the existing protocol, learning even basic facts about an MCP server, such as its name, version or whether it’s still the right endpoint, requires completing the full initialize handshake: open a connection, negotiate capabilities, wait for a response. That’s cheap for one server checked by hand. It’s expensive for a registry trying to index thousands of servers, a client trying to pick the right one from a catalogue, or an agent trying to evaluate several candidate tools before choosing one. SEP-2127 formalises a fix: a static JSON document at a predictable well-known path, so discovery costs one HTTP request instead of a full protocol handshake.
The card itself is deliberately narrow. It carries static metadata only, reverse-DNS name, semantic version, description, website, repository, icons and supported remote transports, and explicitly excludes dynamic runtime information such as the live list of tools, resources or prompts. That’s a considered design choice: a card answers “what is this server and can I reach it,” not “what can it do for me right now.” The specification also ties the card’s shape to server.json as a strict subset, so a server card is the remote-facing slice of the same document a registry would use for a locally-installed package.
How Does This Change the Way Agents Find Tools?
It changes discovery from something a human wires up in advance to something an agent can do at runtime, by reading a URL instead of being told what’s on the other end of it.
Today, an agent’s tool access is almost always the result of a person deciding, ahead of time, which MCP servers to configure. The agent doesn’t find tools; it’s handed a fixed list. Server Cards make it plausible for an agent, or the client acting on its behalf, to crawl a catalogue at /.well-known/mcp/catalog.json, fetch cards from candidate servers, and decide which ones to actually connect to and initialise, all without a person choosing that server by name first. Multi-server hosts can expose several cards under one domain via /.well-known/mcp-server-card/{server-name}, which is the shape you’d expect from a platform hosting many tool providers behind one root.
This is a genuinely different discovery model, and it’s the reason the backlog for this piece filed it separately from the stateless MCP spec change architects are already adjusting to. That earlier change was about what happens once a connection exists: no more session state, no more sticky routing. Server Cards are about what happens before a connection exists at all, and specifically about who, or what, decides a connection should be attempted.
What Trust Problem Does Auto-Discovery Create?
Auto-discovery creates a trust problem the moment a card claiming a capability gets treated as proof the server actually has it, safely, for your organisation.
A Server Card is a claim, not a credential. Nothing in SEP-2127 requires the metadata to be accurate, current, or free of a name collision with something else entirely. The specification is explicit that cards omit primitives precisely because tool lists are dynamic and can’t be trusted as a static snapshot, which means the moment an agent uses a card to shortlist servers worth connecting to, it’s making a decision on data that was never meant to carry that much weight. A server described as a “PDF text extractor” in its card can still request filesystem or network scopes once you actually connect and initialise, and the card gives you no way to know that in advance.
The practical risk isn’t that Server Cards are insecure. It’s that they make it easy to build an agent that discovers and connects to a server nobody in the organisation chose, reviewed or approved, because the whole point of the feature is removing the manual step where that review used to happen. Security researchers already flag this as the next front in MCP asset discovery: finding not just the sanctioned servers but the shadow ones an agent found on its own.
How Should an AI Architect Govern a Server Card Catalogue?
An architect should treat a discovered card as an application to connect, not a connection, and route every application through the same allow-list an agent would need for a manually configured server.
That means three things have to exist before auto-discovery goes anywhere near a production agent: an allow-list of card identifiers (the reverse-DNS name field) the agent is permitted to act on even if discovery surfaces others; a verification step, ideally against a signed or otherwise attested card rather than a bare HTTP response, so a card can’t be spoofed by whoever controls the domain; and an audit log that records which cards an agent evaluated, not just which server it ultimately connected to, so a security review after the fact can see what was on the table and why it wasn’t chosen. None of this is provided by the protocol. It’s the layer an architect has to design, the same way per-tool OAuth scoping had to be designed on top of the stateless spec rather than assumed from it.
| Discovery model | Who decides which server to use | What’s known before connecting | Governance point |
|---|---|---|---|
| Manual configuration (today) | A person, ahead of time | Whatever the person researched | Review happens before the config file is written |
| Server Card auto-discovery | The agent or client, at runtime | Static metadata: name, version, description, transport | Review has to happen against the card, or not at all |
Full initialize handshake | Whoever already chose to connect | Everything, but only after connecting | Too late to be a discovery-time control |
Read across that table, the governance point moves earlier in the pipeline, from “after the config file is written” to “when the card is evaluated,” but only if someone builds that checkpoint. Skip it, and the checkpoint simply doesn’t exist, because nothing in the specification requires one.
Frequently Asked Questions
Are MCP Server Cards live in production yet? SEP-2127 is a draft specification enhancement proposal, not a ratified part of the core MCP spec. Treat it as the direction discovery is heading rather than something every server already supports, and check the current SEP status before committing an integration to it.
Do Server Cards replace the initialize handshake?
No. They sit before it. A card tells a client whether a server is worth connecting to; the handshake still runs once a connection is actually made, and dynamic information like the live tool list only appears at that point.
Can a Server Card be faked? Nothing in the base specification prevents it. The card is served over HTTPS from a domain, which proves domain control, not organisational trustworthiness. Architects who rely on cards for automated decisions should add their own verification layer rather than trusting the document at face value.
Does this replace manual server allow-lists? It shouldn’t. Auto-discovery expands what an agent can find; it doesn’t establish what an agent should be allowed to use. The allow-list moves from “which servers are configured” to “which discovered cards are approved,” but it still needs to exist.
How does this relate to the stateless MCP spec? They’re complementary changes from the same specification effort. The stateless spec removes session state from connections that already exist; Server Cards let a client evaluate a server before a connection exists at all. An architect scoping MCP infrastructure in 2026 needs an answer for both.
Bedrock AI maps your systems, team and workflows to show where AI actually pays, before you spend a pound building. Book a strategy call.