Research guide · MCP · discovery · SEP-2127 · 14 September 2026
MCP Server Cards (SEP-2127): current status, URL and Registry boundary
MCP Server Cards are becoming a serious pre-connection discovery surface, but they are still experimental. The current official extension work says Server Cards are not yet accepted MCP, recommends a /server-card route relative to the Streamable HTTP endpoint, and keeps remote connection metadata deliberately separate from the MCP Registry's server.json package and installation metadata.
Published 14 September 2026 · sources checked 14 September 2026
Experimental
Current extension status
SEP-2127
Proposal
/server-card
Recommended route suffix
Remote only
Card scope
Current status
Treat Server Cards as an experimental discovery contract, not settled core MCP
| Layer | Status | Implementation consequence |
|---|---|---|
| SEP-2127 | Open / in review | The proposal is still under review; do not present it as accepted core MCP. |
| ext-server-card | Experimental | Official prototype schema and examples; explicitly not yet an accepted extension. |
| Recommended card URL | <streamable-http-url>/server-card | Current experimental repository reserves this GET location while allowing any unreserved URI. |
| MCP Registry server.json | Separate | Carries registry/package/local-install metadata rather than replacing the remote Server Card. |
| Tools/resources/prompts | Runtime only | Server Cards intentionally do not enumerate primitives; use standard MCP list operations after connecting. |
The URL trap
Do not hard-code an old well-known path from a stale tutorial
Discovery examples have changed during Server Card design. The current modelcontextprotocol/ext-server-card README says the card may live at any unreserved URI and reserves GET <streamable-http-url>/server-card as the recommended location. That is the shape to target if you are deliberately prototyping against the current experimental extension.
This matters because older public guidance still points implementers at paths such as /.well-known/mcp/server-card.json. A scanner returning 404 on one historical path does not prove a remote MCP server is undiscoverable, and publishing only that path does not prove compatibility with a client following the current extension draft.
Registry boundary
Server Card and Registry server.json solve related but different discovery jobs
A Server Card describes a remote server before connection: identity, version, description, remote transport endpoints, supported protocol versions and optional namespaced metadata. It is designed to help a client decide where and how to connect.
Registry server.json remains the home for package and installation metadata: npm, PyPI, OCI, NuGet or MCPB package information, runtime hints, command-line arguments and environment configuration. If you publish to the official MCP Registry, keep that metadata accurate even if you also experiment with a Server Card.
The card also intentionally omits the live primitive catalog. Do not freeze tools, resources and prompts into a static discovery document and assume they stay authoritative; those are negotiated and listed through MCP at runtime.
Safe adoption path
Publish experimentally without turning a draft into a false compatibility promise
- 1. Keep the Registry record current first. If the server is published in the MCP Registry, preserve one stable identity and accurate
server.jsonpackage/remote metadata. - 2. Target the current experimental schema explicitly. Pin the schema/repository revision you validated instead of assuming an unreleased v1 shape is immutable.
- 3. Serve the card at the current recommended route. For Streamable HTTP experiments, expose the card at the endpoint's
/server-cardroute or another intentionally advertised unreserved URI. - 4. Make card and runtime agree. Identity, version, transport URLs and supported protocol versions should not contradict what the client sees after connecting.
- 5. Do not put secrets or install credentials in the card. It is pre-connection public metadata, not a credential envelope.
- 6. Discover primitives at runtime. Continue to use
tools/list,resources/listandprompts/listwhere supported rather than treating the card as a cached primitive inventory. - 7. Recheck before calling it production compatibility. SEP-2127 is open and the official extension is experimental; graduation can still change the integration boundary.
Why this is timely
The Server Card working group is active today
The official MCP events calendar lists a Server Card Working Group meeting for 14 September 2026, specifically for discussion of the MCP Server Card SEP. That activity makes status language important: builders can experiment now, but documentation should preserve the distinction between working-group momentum and an accepted protocol extension.
Sources
Primary evidence
- modelcontextprotocol/ext-server-card — official experimental extension repository; current status, scope, recommended route and Registry boundary.
- SEP-2127: MCP Server Cards — open, in-review proposal as checked 14 September 2026.
- Server Card discovery notes — experimental discovery semantics and consistency expectations.
- MCP Server Card Working Group · 14 September 2026 — official MCP event listing for the active working-group session.
Continue the discovery path
Make an MCP server discoverable
Registry publication, stable identity and live reachability before adding experimental surfaces.
Verify an MCP server before connecting
Keep discovery evidence separate from the trust decision to expose credentials or state-changing authority.
Registry active but server unreachable
Diagnose publication state separately from the live transport.
Machine API services
Inspect zFinia's machine-readable service surface and live contracts.