Dora NodaPoint an AI agent at a new MCP server today and it has to be told, in advance, by a human: the endpoint URL, the transport it speaks, and — usually after a failed handshake or two — whatever version of the protocol it happens to understand. There's no equivalent of loading a webpage and glancing at the title before you click. The agent either already has the connection details baked into its config, or it opens a full protocol handshake blind and finds out what it's talking to only after the fact.
A draft proposal working its way through the Model Context Protocol's spec process wants to close that gap. SEP-2127, "MCP Server Cards," would let a server publish a small, static JSON file at a predictable .well-known URL — so a registry, a crawler, or an agent can learn what a server is before it ever opens a connection to it. It's a genuinely useful idea for a platform whose whole MCP server exists so an agent can deploy, roll back, and read logs. It's also narrower than it sounds, and the gap between what it sounds like it does and what it actually does is the more interesting story.
What a Server Card Actually Contains
SEP-2127 is still an open, Draft-status pull request — opened January 21, 2026 by an Anthropic contributor, still under active discussion as of this writing — not a merged part of the spec. But the shape of it is concrete enough to build against. A server publishes a JSON document at /.well-known/mcp-server-card (or, for a host running more than one MCP server off the same domain, /.well-known/mcp-server-card/{server-name}). The path choice isn't arbitrary: .well-known is RFC 8615, the same IETF convention that gives browsers /.well-known/security.txt for vulnerability disclosure contacts and gives OAuth clients /.well-known/oauth-authorization-server for discovering an auth server's endpoints without a human typing them in. robots.txt predates the .well-known convention itself, but it established the pattern .well-known later formalized: a predictable path, fetched with a plain unauthenticated GET, that tells an automated visitor something about the site before it does anything more invasive.
Here's what a self-hosted PaaS's own MCP server — the one an AI agent calls to deploy, roll back, or tail logs — would plausibly publish at that path:
{
"name": "co.bex/control-plane",
"version": "2.4.0",
"title": "Bex Control Plane",
"description": "Deploy, rollback, and log access for git-pushed apps running on owned Cluster API infrastructure.",
"websiteUrl": "https://bex.co",
"repository": {
"url": "https://github.com/bex-co/bex",
"source": "github"
},
"remotes": [
{
"type": "streamable-http",
"url": "https://mcp.bex.co/v1",
"protocolVersions": ["2026-07-28", "2026-03-26"]
}
],
"icons": [
{ "src": "https://bex.co/icon-192.png", "sizes": "192x192" }
]
}Read that list of fields again and notice what's missing. There is no tools, resources, or prompts field. Nothing in the current draft schema lets a server advertise deploy_app, rollback_release, or tail_logs — the actual capability surface — at this unauthenticated endpoint. A Server Card tells a client that a server exists, what it's called, where to reach it, and which protocol versions it speaks. It does not tell a client what the server can do.
Why the Omission Is Deliberate, Not an Oversight
That gap looks, at first read, like an obvious next feature someone forgot to add. It isn't. The SEP's own text addresses it directly: a client "might trust a static manifest's tool descriptions for access-control or safety decisions, when the actual primitives at runtime may differ." That's a precise problem, not a hand-wave. A server's real tool list depends on things a static file can't see — which scopes the requester's OAuth token actually carries, which feature flags are on for that tenant, which tools a given deployment has been configured to expose at all. A cached server-card.json that claims a deploy_app tool exists, fetched an hour before the platform operator disabled write access for that client's token, is worse than no manifest at all: it's a manifest a client can be talked into trusting for exactly the kind of authorization decision it's least equipped to make correctly.
So the boundary SEP-2127 draws is narrower than "advertise your tool surface" — it's "advertise that you exist, and let the actual capability negotiation happen only after a real connection, against real credentials." That's a smaller promise than the discovery pattern's robots.txt/security.txt framing might suggest. It's also the correct one: a stale sitemap costs you a 404. A stale capability manifest that a client's access-control logic leaned on costs you an agent confidently attempting — or worse, an authorization layer confidently permitting — an action the server was never actually going to allow.
What Pre-Connection Discovery Still Buys You
None of that makes the Server Card pointless — it just relocates the payoff from "know what it can do" to "know whether it's worth connecting to." And that's a real, measurable cost today. Compare the two paths a client currently has for finding out anything about an MCP server:
Without a Server Card, an agent (or a registry crawler indexing MCP servers on behalf of agents) has exactly one way to learn anything: open a connection and run the protocol's initialize handshake — negotiate a protocol version, exchange capabilities, and only then find out whether the server was even reachable, authenticated correctly, or worth the round trip at all. Every one of those checks costs a live connection, and for a crawler trying to catalog thousands of servers, that means thousands of live connections just to build an index entry.
With a Server Card, the same information — does this server exist, what's it called, what transport and protocol versions does it speak, where's its source — comes back from one cacheable, unauthenticated GET. The official MCP Registry already indexes servers this way in spirit (name, description, repository, namespace-verified identity); a Server Card is the same shape of metadata, but self-published and fetchable directly from the server itself rather than only from a third-party listing.
This lands in the same year MCP is separately getting faster to actually connect to, for a different and already-shipped reason. The July 28, 2026 MCP specification release — a real, merged change, not a draft SEP — removed the protocol-level session entirely: no more Mcp-Session-Id header pinning a client to one server instance, no more shared session store for horizontally-scaled deployments. It also added a server/discover method, letting a connected client fetch capabilities on demand instead of only at handshake time. That's a genuinely separate mechanism from Server Cards — server/discover runs after a connection is open and authenticated; a Server Card runs before one exists at all — but the two are aimed at the same underlying complaint: MCP has historically made you connect first and ask questions later, at every layer, and 2026 is the year both the pre-connection and post-connection versions of that problem are getting addressed, on separate tracks, by separate proposals.
Should a Self-Hosted Platform Actually Publish One?
Given what a Server Card really contains — no tool names, no credentials, just identity, version, transport, and a repository link — the decision to publish one is a smaller risk than "advertising your full tool surface" would suggest. But it's not zero-risk, and it isn't the same call for every deployment shape a self-hosted PaaS ships in.
For a platform's own public control-plane MCP endpoint — the one at a fixed, known domain like mcp.bex.co, serving every tenant on the hosted offering — publishing a Server Card costs almost nothing and buys real discoverability: a registry can list it, a new agent integration can autoconfigure against it without a human copying a URL out of documentation, and a client can pick the right protocol version without a failed handshake first.
For a self-hosted, single-tenant instance running on infrastructure a customer owns — behind their own domain, on their own Cluster API fleet — the calculus is different, and it's worth being honest about why even a card with no tool names in it still leaks something. The mere presence of a Server Card at customer-domain.com/.well-known/mcp-server-card confirms, to anyone who thinks to check, that this domain runs an MCP-callable control plane with deploy/rollback/log-access semantics — the description field alone says that much. For a public SaaS that's advertising, not a leak. For a self-hosted instance whose whole value proposition is that the operator controls its own attack surface, that's a disclosure the operator should opt into deliberately, not inherit by default because the platform's MCP server template ships one unconditionally. A sensible default: publish the Server Card on the hosted control plane, ship it disabled on self-hosted installs, and let the operator flip it on if they actually want their instance discoverable.
That's the same shape of design choice that runs through everything else in this space — the discovery layer and the authorization layer have to be reasoned about separately, because a mechanism that's harmless at the metadata level can still be a decision an operator deserves to make themselves. It's also exactly why an agent's deploy and rollback tools belong behind the same authenticated MCP boundary the platform already enforces, whether or not a Server Card ever tells anyone that boundary exists.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, and give an AI agent the same deploy/rollback/logs tools over MCP that a human operator uses. Star the repo on GitHub or deploy your first app today.