MCP Server Cards and Draft Service Discovery

A client needs an endpoint before it can speak MCP. A Server Card can supply that connection information, but it cannot tell the client which tools a particular user will be allowed to call after authentication.

As of September 9, 2026, SEP-2127 remains open. The experimental Server Card repository explicitly describes its work as unaccepted experimental material. It should be evaluated separately from the stable MCP 2026-07-28 protocol.

I would keep a card small enough to audit against the server it names. A static catalog is a reasonable place for connection hints; personalized tool permissions belong to the authenticated runtime.

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 MCP Registry owns the broader server.json format for locally installable packages and their runtime configuration. The experimental card schema now focuses on remote connectivity rather than defining a registry-shaped superset. Namespaced extension metadata may carry additional hints, but clients shouldn't turn an unreviewed hint into permission to install or execute a package.

The current experiment uses an AI Catalog

The extension's discovery document now points to an AI Catalog at:

/.well-known/ai-catalog.json

This replaces the earlier MCP-specific catalog path in this article. A catalog entry identifies its artifact type, then either supplies a url or embeds the complete card in data. Those two forms are alternatives. Domain discovery selects entries with type application/mcp-server-card+json; a hosted card is requested with that media type in Accept.

The proposed default for a hosted card remains GET <streamable-http-url>/server-card. For https://host.example/mcp, that produces https://host.example/mcp/server-card. An explicit catalog URL can name another location. Clients should follow the entry rather than guess a second path if the first fetch fails.

An illustrative URL-backed entry makes the separation visible:

{
  "specVersion": "1.0",
  "entries": [{
    "identifier": "urn:air:example.com:mcp:reports",
    "type": "application/mcp-server-card+json",
    "url": "https://example.com/reports/server-card"
  }]
}

This locates a card. The card then supplies the remote connection details; neither document lists the authenticated user's permitted tools.

A cross-domain entry creates another origin to review. An inline card avoids that fetch but carries the same untrusted endpoint metadata. Neither form inherits approval simply because it appeared in a catalog.

These details are a snapshot of experimental work, not released discovery requirements. Pin the repository revision in a prototype and test migration when the catalog or schema changes. The July version of this article used /.well-known/mcp/catalog.json; preserving that URL in new client code would preserve an obsolete experiment.

The catalog and card also need separate cache keys and lifetime decisions. Replacing an entry must eventually stop clients connecting to its old target. Test that change explicitly before depending on cached discovery.

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. Compare the declared identity, transport, and protocol support with the live exchange available in the implemented MCP version. The extension's current draft also references server/discover; that reference doesn't make the experimental card an accepted feature. Surface a mismatch and apply local connection policy before continuing.

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.

Require a successful connection before advertising it

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.

A prototype should demonstrate both permitted and refused connections: a current card reaching the intended server, a changed origin being stopped for review, and an authenticated user seeing only their permitted tools. Until there is a public server to exercise, this publishing origin has no card or AI Catalog entry to publish.