MCP Server Cards are a proposed metadata standard for the Model Context Protocol, first named in the roadmap MCP’s lead maintainers published on August 22, 2026, that would let a server expose discoverable information at a .well-known URL so a registry or crawler can find and evaluate it without connecting first. They are not shipped yet — no schema or ship date has been published — but they signal where MCP server discovery is headed next, barely three weeks after the protocol’s stateless specification went final.
The timing matters. The 2026-07-28 specification finished the job of making a remote MCP server behave like any other HTTP workload, and MCP’s Tier 1 SDKs were already passing close to half a billion downloads a month by that release. With the protocol core settled, the maintainers’ next roadmap turns to a problem the spec itself doesn’t solve: with tens of thousands of servers now scattered across a handful of directories that each crawl and dedupe differently, how does a client — human or AI agent — find the right one and trust what it’s being told about it? Server Cards, under a newly named Server Card Working Group, are the maintainers’ first formal answer to that question.
There is no single best way to discover an MCP server today, and that won’t change the moment a Server Card schema ships either. Glama ranks first for the deepest enriched, human-browsable metadata — quality scores, security audits, and a live sandbox across 77,220 servers verified as of August 24, 2026. MCPfinder ranks second as the strongest agent-native option: it is itself an MCP server that an AI agent calls mid-task, already aggregating three separate registries into one queryable index, which makes it the closest existing analog to what a Server Card-consuming client would need to do. The Official MCP Registry is the spec’s own canonical index and the most likely eventual home for Server Card metadata, but it is still explicitly labeled “in preview” a full month after the underlying protocol went final.
What the roadmap actually proposes
The August 22 post lists five priorities, and server discovery is only one of them: agentic messaging primitives (server-initiated webhooks and channels), HTTP-native transport unification, agent identity and enterprise security (Demonstrating Proof of Possession, workload identity federation, engagement with IETF and WIMSE working groups), improved primitives including progressive tool-catalog discovery, and SDK developer-experience work. Server Cards sit inside that fourth bucket, described in the roadmap as letting “a server be discovered and reasoned over without connecting to it” — the same design goal as a robots.txt or security.txt file, applied to MCP servers. Independent coverage from WorkOS describes the same mechanism as “a proposed standard for exposing server metadata via .well-known URLs so browsers, crawlers, and registries can discover capabilities without connecting,” which corroborates the roadmap’s own framing but adds no further specifics — a sign this is genuinely early-stage working-group territory, not a near-final draft with details being withheld.
Why aggregators are better positioned than single-source directories
A protocol-level metadata standard rewards tools that already normalize structured data from more than one source, because that is functionally what a Server Card consumer has to do at scale. MCPfinder already pulls from the Official Registry, Glama and Smithery into one schema and computes its own confidence score and staleness warnings — the same shape of work a client reading Server Cards across many independent servers will need to do, just with the source-of-truth eventually shifting from three third-party directories to metadata the servers publish themselves. Glama’s advantage is different: it already does deep, per-server enrichment (security audits, health checks, a sandbox) that goes beyond what a lightweight .well-known file is likely to carry, so it is less about being replaced by Server Cards and more about eventually consuming them as one more input alongside its existing scoring.
The gap between “final spec” and “usable discovery” hasn’t closed
The most concrete, checkable fact in this report is also the least flattering one for the ecosystem’s own tooling: the Official MCP Registry — built and endorsed by Anthropic, GitHub, PulseMCP and Microsoft, and the natural home for a future Server Card index — is still labeled “in preview” on its own documentation, verified August 24, 2026, nearly a month after the 2026-07-28 specification it supports went final. That gap is precisely the discovery problem this new roadmap is trying to close, and it’s a useful signal for buyers: don’t assume “the protocol is final” means “the tooling around it is production-ready.” Directory freshness needs the same scrutiny — PulseMCP, normally one of the cleaner browsing experiences in the category, had new submissions and listing changes paused mid-August 2026 for an ingestion rework, verified as of this writing.
Where this leaves buyers today
Nothing in the new roadmap changes which tool to use right now, because Server Cards aren’t live. If you’re a person browsing for a server to add to Claude Desktop, Cursor or Windsurf, Glama’s enrichment is the most useful starting point. If you’re building an agent that needs to search for and install a server autonomously mid-task, MCPfinder is the only entrant here designed to be called that way rather than browsed. The one durable takeaway from the roadmap itself is directional: expect discovery to keep moving from “pick a directory and trust its listing” toward “read structured, checkable metadata directly from the source,” and the tools that already do something close to that today are the ones best placed to adopt whatever schema the Server Card Working Group eventually publishes.