🤖 Drafted by Claude Code (an AI coding agent) on behalf of @tadasant. The substance was reviewed by a human before filing.

Summary

SEP-2127 (MCP Server Cards) is currently a Standards Track SEP carrying ~320 lines of inline wire-format detail — JSON schemas, field tables, .well-known endpoint mechanics, security considerations, and IETF registration. Now that Server Cards are being incubated as an experimental extension in modelcontextprotocol/experimental-ext-server-card, the SEP should be refactored to Extensions Track and slimmed to a charter that delegates the detailed specification to that repo — following the precedent set by SEP-1865 (MCP Apps).

This isn't just a relabel: per SEP-2133, an extension's detailed spec is supposed to live in its ext-* repository, with the SEP acting as the chartering document that names the working group and points to that repo.

Why Extensions Track is the right home

The Extensions Track was established by SEP-2133 ("Extensions", Final). Its defining text (seps/2133-extensions.md, under Lifecycle → Creation):

To become an official extension, extensions are created via a SEP in the main MCP repository using the standard SEP guidelines but with a new type: Extensions Track. This type follows the same review and acceptance process as Standards Track SEPs, but clearly indicates that the proposal is for an extension rather than a core protocol addition. The SEP must identify the Working Group and Extension Maintainers that will be responsible for the extension.

And the detailed spec is explicitly meant to live in a repo, not the SEP:

An extension is a versioned specification document within an extension repository, e.g. https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/draft/oauth-client-credentials.mdx

SEP-2133 even charters the exact incubation pattern Server Cards is already in — an experimental-ext- repo created while the SEP is in draft:

An experimental extension repository is a repository within the official modelcontextprotocol github org with the experimental-ext- prefix… To graduate an experimental extension to official status, the standard SEP process (Extensions Track) applies. The experimental repository and any reference implementations developed during incubation MAY be referenced in the SEP to demonstrate the extension's practicality.

Server Cards fit this description squarely: it's an optional, opt-in discovery mechanism layered on top of the core protocol — "an interoperability standard supported outside the core specification" — not a change to the core wire protocol.

What SEP-2127 looks like today

From the current PR-head version (seps/2127-mcp-server-cards.md @ aa59517), frontmatter:

- **Status**: Draft
- **Type**: Standards Track
- **Author(s)**: David Soria Parra (@dsp-ant), Nick Cooper (@nickcoai), Tadas Antanavicius (@tadasant)

It carries the full detailed spec inline (line anchors at aa59517):

• ### MCP Server Card Schema (L80–158) + Field Descriptions (L159–175)
• ### server.json Schema (L176–248)
• ### Endpoints / #### .well-known URI (L257–305)
• ## Security Implications (L354–384)
• ## IETF Registration (L389–399)

It also has no Extension Identifier field, no Working Group attribution in the author line, and — notably — does not reference its own experimental repo anywhere (its Reference Implementation section is still "To be added."). Meanwhile experimental-ext-server-card already holds schema.ts, the generated schema.json, docs/discovery.md, and examples — i.e. the detail SEP-2127 currently duplicates — and its README states it "tracks SEP-2127." The pairing physically exists; the SEP just hasn't been restructured to reflect it.

Precedent: what "Extensions Track" looks like in practice

There are exactly two Final Extensions Track SEPs today (SEP index), and they bracket the design space:

SEP-1865 — MCP Apps (the model to follow). 153 lines, charter-shaped. It delegates the full schema to ext-apps via a <Note> at the top (seps/1865-…md):

The full extension specification is maintained in the ext-apps repository.

…and its entire ## Specification section is a high-level pointer + bullet list of what the extension introduces — no inline JSON schema, no field tables. This is exactly the shape SEP-2127 should take: Abstract / Motivation / Rationale / Security posture / WG + maintainers + a pointer to experimental-ext-server-card, with the schema and .well-known mechanics living in the repo.

SEP-2663 — Tasks (the honest counter-example). Also Extensions Track, but 966 lines with the full spec kept inline. Its frontmatter shows the two Extensions-Track conventions SEP-2127 is missing (seps/2663-…md):

- **Type**: Extensions Track
- **Author(s)**: Luca Chang (@LucaButBoring), Caitie McCaffrey (@CaitieM20); on behalf of the Agents Working Group
- **Extension Identifier**: `io.modelcontextprotocol/tasks`

So the track does not mandate delegation — SEP-2663 proves a SEP may carry the full spec. The argument here is that SEP-2127 should follow the lighter SEP-1865 shape because the detailed spec already lives (and is being actively iterated) in experimental-ext-server-card, and keeping a second copy inline guarantees drift (we already have concrete drift bugs open against the repo copy: see the related issues below).

Proposed refactor

1. Change Type: Standards Track → Extensions Track.
2. Add Extension Identifier (e.g. io.modelcontextprotocol/server-card) and Working Group attribution (the Server Card Working Group) to the frontmatter, per SEP-2663's convention.
3. Slim the body to a charter, SEP-1865 style: keep Abstract, Motivation, Rationale, a high-level Specification pointer, Security posture summary, and the WG/maintainers. Move the detailed normative content — MCP Server Card Schema, server.json Schema, field tables, .well-known Endpoints, full Security Implications, IETF Registration — out of the SEP; its home is experimental-ext-server-card (graduating to an ext-server-card repo on acceptance).
4. Add a top-of-file pointer to experimental-ext-server-card as the spec home (closing the current one-directional cross-reference), mirroring SEP-1865's <Note>.
5. Satisfy the reference-implementation requirement SEP-2133 imposes before Final (an SDK reference implementation), and reference the incubation work in the SEP.

Notes / caveats

• The published guidelines are stale. sep-guidelines.mdx and seps/TEMPLATE.md still list only three types (Standards Track / Informational / Process) — the Extensions Track added by SEP-2133 was never backfilled. An Extensions Track relabel will therefore look novel to a casual reader even though SEP-2133 + two Final SEPs establish it. Backfilling the guidelines/template is probably worth a separate process issue.
• Process venue. Per the SEP guidelines, changes to an in-review SEP belong on the SEP's PR: "For SEPs not yet reaching final state, comment directly on the SEP's pull request." Since SEP-2127 is still Draft on PR #2127, the actual track change should be driven there; this issue is the durable process record and can be cross-linked from the PR.
• Related drift bugs (in the extension repo, arguing for a single source of truth): MCP Catalog mediaType (application/mcp-server+json) diverges from AI Catalog's application/mcp-server-card+json experimental-ext-server-card#9 (media-type divergence), Allow specifying timeouts for most operations #10 (primitives contradiction), Add description to Resource #11 (.well-known path spelling).