MCP Server Cards and Draft Service Discovery
What current draft SEP-2127 proposes for MCP Server Cards, catalog discovery, runtime checks, and stale metadata risk.
An MCP client can learn a server's name and capabilities during initialization, but it already needs a connection endpoint to get that far. MCP Server Cards aim to supply limited connection metadata before the client connects.
The mechanism remains draft work. As of July 16, 2026, the current open proposal is SEP-2127, an Extensions Track draft sponsored through the Server Card Working Group. The detailed schema and discovery mechanics live in the official organization's experimental Server Card extension repository.
Neither a candidate path nor today's schema should be presented as settled MCP behavior.
The proposed card is deliberately smaller than runtime MCP
The current TypeScript schema is the draft source of truth. It describes a remote server's identity and connection details: a reverse-DNS name, version, short description, optional title, website, repository, icons, remote endpoints, headers, configuration variables, and supported protocol versions. A generated JSON Schema describes the same provisional shape.
The card has a draft media type of application/mcp-server-card+json. It includes a $schema URI so validators can select the expected document family.
Tools, resources, and prompts are intentionally absent. Those primitives can differ by authenticated user, tenant, server configuration, feature selection, and current deployment. A public static card cannot describe that personalized surface reliably.
Runtime list operations remain authoritative for primitives. That design reduces the chance that a client treats an old public tool list as current authorization. It also keeps the card focused on the information required to attempt initialization.
The broader server.json shape is a strict superset intended to cover locally runnable packages as well as remote connections. SEP-2127 excludes package execution from the public card because a decentralized document that tells a client what to install would create a much larger execution risk.
Current candidate discovery uses a catalog
The extension repository's current discovery document proposes an MCP Catalog at:
/.well-known/mcp/catalog.json
The draft catalog contains a specVersion and an entries array. Each entry uses an identifier, the card media type, and a URL where the client can fetch the full Server Card. A catalog may point to a card on another domain, which supports a service whose remote MCP endpoint is operated by a hosting provider.
After reading a catalog entry, the client follows its URL and requests the card with:
Accept: application/mcp-server-card+json
The current draft reserves a recommended default at GET <streamable-http-url>/server-card. If a server's Streamable HTTP endpoint is https://host.example/mcp, that convention produces https://host.example/mcp/server-card. A card may live at another unreserved URI because the catalog gives its exact URL.
This differs from earlier SEP text and prior proposals that showed a single Server Card under a .well-known path. The current extension draft rejects that placement for the individual card: site-wide catalog discovery belongs under .well-known, while server-specific application metadata is reached through the catalog entry. It also rejects overloading the bare Streamable HTTP endpoint, where GET already has transport meaning.
All of these locations are candidate mechanics. The pull request is open, its label is draft, and the extension repository says the protocol revision is draft. Implementations should pin a revision, test it as experimental, and plan for migration.
Schema URIs and media types are provisional as well. Cache them with the document revision used by the implementation, reject unknown breaking versions, and avoid hard-coding today's examples into a permanent client compatibility promise.
A card is advisory metadata
HTTPS protects a card while it is transferred from the selected host. It doesn't prove that the remote MCP server will match the document after connection.
A card can become stale after an endpoint move or protocol upgrade. It can overstate supported versions, refer to a retired transport, or display a server identity that runtime initialization contradicts. A malicious catalog can point to an attacker-controlled card. A malicious card can supply an external endpoint or describe a secret configuration header.
The draft therefore tells clients not to use card contents as authority for security or access control. Once connected, compare the declared name, version, transport, and protocol support with the live server. Prefer runtime values when they disagree and surface the mismatch for assessment.
Network retrieval needs its own policy. Permit expected HTTPS schemes, cap redirects and bytes, revalidate the destination and resolved address on every hop, reject local and private destinations in backend fetchers, enforce JSON parsing limits, and isolate caches by catalog origin and card URL. Cross-domain entries should be visible to the user before connection.
Configuration inputs require classification. A card field that marks a value as secret can help a client choose protected storage, but self-asserted metadata cannot demand a credential. The user or administrator should approve which secret is released to which validated origin. Never place an access token directly in a public card.
Caching improves discovery performance while raising stale-data exposure. Honor bounded HTTP cache policy, refresh on connection failures, and avoid persisting a card beyond the operator's tested update window. Catalog and card monitoring should compare public metadata with production initialization.
Discovery doesn't replace authentication or authorization
A Server Card may tell a client where a Streamable HTTP server lives. OAuth Protected Resource Metadata tells the client which authorization server may issue a token for that protected resource. MCP initialization negotiates live protocol details. Tool listing then shows what the authenticated session can see.
Keep those stages separate. A card must not embed credentials, claim that a user is authorized, or cause a client to bypass a 401 challenge. The remote server still validates issuer, audience, token lifetime, scopes, sender constraints, tenant membership, and operation-level policy.
The proposed catalog also isn't the MCP Registry. A registry has its own publisher and moderation model. Decentralized catalog discovery starts with the domain and should not inherit a registry's review status.
Why TKOResearch publishes no card
TKOResearch does not operate a public remote MCP server. A catalog with no maintained server, or a card that points at an ordinary website route, would advertise an integration surface that cannot complete MCP initialization.
If TARE later exposes remote MCP, adoption should follow the accepted extension revision. The launch gate needs a maintained transport, exact OAuth resource metadata where protected, runtime consistency checks, configuration-secret handling, cache policy, monitoring, and an owner who updates the card with each compatible release.
Until then, the absence of /.well-known/mcp/catalog.json and Server Cards is intentional. Draft discovery metadata should follow a deployed MCP service, not stand in for one.