MCP Bets H2 2026 on Server Cards: What Your Registry-Less Server Must Hand-Roll Today

On March 9, 2026, MCP lead maintainer David Soria Parra published the 2026 roadmap with a two-part promise under Transport Evolution: servers that scale horizontally without holding state, plus "a standard metadata format, that can be served via .well-known, so that server capabilities are discoverable without a live connection." The first half landed on July 28, when the 2026-07-28 spec revision deleted the initialize handshake and server-side sessions outright. The second half — Server Cards, the machine-readable manifest that lets an agent find and evaluate your server without a human pointing it at a URL first — is still an experimental draft with its well-known path unfrozen and its SEP under review.

That split is the whole story for anyone running a deploy-from-chat MCP server today. Here is exactly where each piece of the H2 discovery bet stands, and what you hand-roll in the meantime:

The gap between row two and row three is where registry-less servers live: an agent that has never been told your server exists cannot call server/discover, because that RPC requires a connection. Something has to be fetchable before the connection. That something is what you build yourself, and if you build it in the spec's direction, the day Server Cards land as a MUST is a format migration — not a rewrite.

What "discoverable by an agent never told you exist" actually requires​

Strip the roadmap language down and automatic discovery decomposes into three concrete requirements. Each maps to one thing you hand-roll:

1. A fetchable manifest at a predictable URL. The agent starts from a domain, not an endpoint. It needs a document it can GET without credentials, without a handshake, and without knowing your URL layout — the .well-known convention exists precisely for this.
2. Capability advertisement the agent can evaluate pre-connect. Not just "this is an MCP server," but which protocol versions it speaks, which tools it offers, and what authentication each path requires — enough for the agent to decide this server can deploy my app before spending a connection on it.
3. Trust signaling. A manifest is a self-description, and self-descriptions from the open internet are worthless without a voucher. Something has to answer why should the agent believe this server is who it claims to be — a registry namespace, a verified domain, a signature chain.

The spec will eventually own all three. Today it owns none of them pre-connect — and the registry preview explicitly does not support private servers, recommending you host your own instead. So a registry-less deploy-from-chat server builds all three itself. The rest of this post does that concretely, using one running example: a PaaS MCP server exposing deploy, rollback, and logs tools at mcp.example-paas.com.

Hand-roll #1: the well-known manifest​

Serve a static JSON document over HTTPS at a .well-known path on your server's domain. The Server Card working group has not frozen the path — the ecosystem currently shows /.well-known/mcp.json, /.well-known/mcp/server-card.json, and /.well-known/mcp/catalog.json in competing drafts — so serve the same document at two candidate paths and treat the path as configuration, not contract. What matters is the shape, because the working group has committed to one convergence rule: the Server Card format will stay as close as possible to a subset of the registry's server.json. Build your manifest as that subset today and the eventual migration is mechanical.

For the running example, the manifest answers the three pre-connect questions — who are you, what do you offer, how do I authenticate — in one fetch:

{
  "name": "com.example-paas/deploys",
  "description": "Deploy, roll back, and tail logs for apps on Example PaaS.",
  "protocolVersions": ["2026-07-28", "2025-11-25"],
  "endpoint": "https://mcp.example-paas.com/mcp",
  "tools": [
    {"name": "deploy", "destructiveHint": true, "requiresAuth": true},
    {"name": "rollback", "destructiveHint": true, "requiresAuth": true},
    {"name": "logs", "readOnlyHint": true, "requiresAuth": true}
  ],
  "authorization": {
    "type": "oauth2.1",
    "issuer": "https://auth.example-paas.com",
    "metadataUrl": "https://auth.example-paas.com/.well-known/oauth-authorization-server"
  }
}

Three deliberate choices here. First, protocolVersions lists newest-first with the previous revision retained, because the 2026-07-28 spec made version negotiation per-request and dual-era clients will coexist for a year. Second, the tool entries carry the spec's safety annotations (destructiveHint, readOnlyHint) — the only machine-readable signal a client has for whether a tool is safe to try — so an agent can decide deploy needs confirmation, logs does not before connecting. Third, auth points at standard OAuth discovery metadata rather than inventing a field, because the authorization-server metadata document is the one trust-adjacent standard that already exists and already works.

Hand-roll #2: capability advertisement that matches server/discover​

Your manifest is a static promise; server/discover is the live confirmation. The 2026-07-28 spec requires every server to implement that RPC, returning supported protocol versions, capabilities, and identity so a client can select a version up front or probe for backward compatibility. The failure mode to avoid is drift: the manifest says one thing, the RPC says another, and the agent that trusted the manifest wastes a connection — or worse, plans around a tool that is not there.

The fix is structural, not procedural: generate both surfaces from one source of truth. Keep a single server-description object in your codebase and render it twice — once as the static .well-known document, once as the server/discover result. For the running example, the same deploy / rollback / logs inventory, the same version list, and the same identity string flow into both. A deployment that adds a fourth tool updates one structure and both surfaces move together; no checklist, no second PR, no drift window.

This is also the design that makes Server Cards landing painless. When the card format freezes, you are not building a discovery layer — you are adding a third renderer to an object you already maintain. The teams facing a rewrite will be the ones whose manifest is a hand-edited static file, whose server/discover is hardcoded in a handler, and whose registry entry was typed into a web form: three descriptions of one server, diverging from the day they were written.

Hand-roll #3: trust without a registry​

This is the hardest of the three, and the one where honesty matters most: nothing you hand-roll fully replaces a registry's voucher function. The preview registry's trust story is DNS-verified namespaces — io.github.user/server-name means someone proved control of that namespace — consumed mostly by downstream aggregators that add curation on top. A registry-less server has to assemble an equivalent chain from weaker links:

• Serve the manifest from your verified domain over HTTPS. mcp.example-paas.com/.well-known/... inherits whatever trust the agent places in that domain and its TLS certificate. This is the floor, not the ceiling — it defeats impersonation-by-typo-squat only if the agent already knows your domain, which for a first-contact agent it may not.
• Publish standard OAuth authorization-server metadata. An agent that can fetch your issuer's metadata document and complete a normal OAuth 2.1 flow gets authentication it can reason about, instead of a bespoke token dance it cannot evaluate. Strong auth does not prove you are the right server, but it proves you are a real one with an account system behind it.
• Design for the identity work already on the roadmap. The current roadmap puts agent identity front and center: DPoP proof-of-possession, Workload Identity Federation (SEP-1933), and token exchange for agents acting without a present user. You cannot implement drafts, but you can keep your auth layer shaped like the standards they extend — OAuth 2.1 issuers, short-lived tokens, no pasted API keys — so adopting them is configuration, not surgery.

One more thing, specific to the running example: deploy and rollback are destructive tools, and destructive tools raise the trust bar. A read-only logs tool served from an unknown server is a minor risk; a deploy tool that pushes to production from an unknown server is how supply-chain incidents happen. Until a registry or signed-card chain vouches for your server, the responsible posture is to make destructive tools the last thing an unknown agent can reach: require authenticated identity, require explicit per-tool authorization, and say so in the manifest itself via the safety annotations. Discovery without a trust story is just a faster way to find servers you should not call.

Where A2A fits (and doesn't)​

H2 2026 commentary often pairs Server Cards with "deeper A2A coordination," and the layering matters because the two cards sound interchangeable. They are not. A2A — Google's agent-to-agent protocol, donated to the Linux Foundation in June 2025 and at v1.0 since spring 2026 — standardizes how agents delegate tasks to each other: Agent Cards advertise an agent's capabilities, and the protocol defines task lifecycle across synchronous, streaming, and asynchronous modes. The industry shorthand is exact: MCP inside agents, A2A between agents.

For a deploy-from-chat server, that means A2A answers a different question. Server Cards tell an agent what tools this server offers; A2A lets that agent hand the deploy task to a specialist sub-agent with narrower authority than its own. Adopting A2A does not make your MCP server discoverable, and publishing a Server Card does not give you delegation. The H2 roadmap's "foundational multi-agent infrastructure" framing needs both layers, but they compose — they do not substitute. Build the Server Card direction now; track A2A for the day your deploy agent starts spawning helpers.

What to skip until the spec lands​

A do-not-build list is as valuable as the build list, because every wrong bet here becomes migration debt:

• Don't invent a private registry protocol. The official registry's own docs tell private-server operators to host their own registry — but "your own registry" should mean the standard registry API and server.json shape behind your SSO, not a bespoke catalog format no client will ever implement. If you need private listing before Server Cards freeze, mirror server.json exactly.
• Don't hard-code the card path. With the working group still choosing between well-known paths and resource-based discovery, any literal path you commit to is a guess. Serve your manifest at the leading candidate paths and read the path from configuration, so tracking the WG decision is a one-line change.
• Don't skip server/discover while waiting for cards. This one cuts the other way: server/discover is already a MUST in a shipped spec revision, and every 2026-07-28 client is entitled to call it. Pre-connect discovery is the future; in-band discovery is the law. Ship the law first.

Build toward the spec, not around it​

Six months ago the roadmap asked for two things: stateless servers and discoverable servers. The protocol delivered the first in July and chartered a working group for the second — with the format explicitly converging on a server.json subset and the group's initial charter term closing in mid-August 2026. That is about as clear a "build in this direction" signal as standards work ever gives: the shape is known, the path is not, and the migration will reward anyone whose manifest, RPC response, and registry entry are three renderings of one object.

The agent that has never been told your server exists is coming. It will start from a domain, fetch a manifest, evaluate capabilities and trust, and only then connect. Hand-roll that sequence today — manifest, matching server/discover, honest trust signaling with destructive tools gated hardest — and Server Cards landing as a MUST changes your format string, not your architecture.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.