- TypeScript 100%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
## Summary Removes the `displayName` field from **MCP Catalog** entries in `docs/discovery.md`. An MCP Catalog entry now requires only `identifier`, `mediaType`, and `url` — there is no human-readable-name field on the entry at all. Resolves #14. ## Rationale Issue #14 originally proposed making `displayName` **optional**, gated on the upstream AI Catalog spec doing the same. That gate resolved — **Agent-Card/ai-catalog#39** ("make Catalog Entry displayName optional (not required), ADR 0016") **merged** 2026-06-26: https://github.com/Agent-Card/ai-catalog/pull/39. But for the **MCP-scoped** catalog we can go one step further and drop the field entirely, which is cleaner: - Every MCP Catalog entry references a **Server Card**, and the Server Card's `title` is the source of truth for the server's human-readable name. A client fetches that card anyway (the discovery flow retrieves the card at `url` for connection details), so it can read the name straight from the card. - Documenting `displayName` on the entry — even as optional — only invites publishers to duplicate a name that already lives in the card, where it can drift out of sync. This is the general-AI-Catalog concern (some non-MCP/non-A2A artifacts have no baked-in name) not applying to us: an MCP entry *always* points at a card that carries its own `title`. This still **preserves the drop-in-subset guarantee**. AI Catalog makes `displayName` optional (ADR 0016), so an MCP Catalog entry that omits it remains valid as-is inside a full AI Catalog document. The two specs agree; MCP simply declines to use the field and defers to the Server Card's `title`. The doc states this explicitly so the intentional omission is clear rather than looking like an oversight. ## What changed (`docs/discovery.md` only) - **Catalog Entry table**: removed the `displayName` row. Entry now lists only `identifier`, `mediaType`, `url` (all required). - **Prose**: replaced the required/optional language with a paragraph explaining that the entry carries no name field and clients read the name from the referenced Server Card's `title`, plus a paragraph documenting the AI-Catalog compatibility (optional `displayName` upstream → MCP entry is still a drop-in subset). - **Examples**: removed `displayName` from the single-server example and from all three entries in the multiple-servers example. Docs/spec-text only. No TypeScript or JSON Schema changes were needed — the catalog entry shape lives entirely in `discovery.md`; `schema.ts`/`schema.json` describe the Server Card itself and never encoded the catalog entry's `displayName`, so there was no schema coupling to update. ## Verification - [x] `npm run check` passes (schema.json up to date; `tsc --noEmit` clean) — docs-only diff - [x] `npm run validate` passes (all 7 Server Card examples validate as expected) - [x] `npm run format:check` clean for `docs/discovery.md` (ran `prettier --write`; remaining warnings are AO-injected untracked files not present in CI) - [x] Whole-file `displayName` sweep: the field is gone from the table and every example; the only remaining mentions are the deliberate AI-Catalog compatibility note explaining why MCP omits it — no contradictory "required"/"optional-field" language remains - [x] CI green on this PR (build, CodeQL, Analyze — see checks) - [x] Independent fresh-eyes review performed via in-session subagent; feedback addressed --------- Co-authored-by: tadasant <peter@tadasant.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
| .github/workflows | ||
| docs | ||
| examples/ServerCard | ||
| scripts | ||
| .gitignore | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| LICENSE | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| schema.json | ||
| schema.ts | ||
| tsconfig.json | ||
MCP Server Cards (Experimental Extension)
Status: Experimental. This work is for prototyping and feedback only, and is not an accepted or official MCP extension.
This repository defines a TypeScript source-of-truth and generated JSON Schema for MCP Server Cards. Server Cards are a static metadata document that describes a remote MCP server enough for clients to discover and connect to it.
It tracks SEP-2127 and is intended to be lifted directly into the main spec when Server Cards graduate (see Graduation plan below).
A prior attempt to land these types directly in the core spec (modelcontextprotocol#2652) is being relaunched here as an experimental extension while the SEP itself is still under review.
What is a Server Card?
A Server Card is a JSON document — hosted at any unreserved URI, with GET <streamable-http-url>/server-card reserved as the recommended location (see discovery.md) — describing:
- The server's identity (
name,version,description, optionaltitle/icons/repository/websiteUrl) - Its remote transport endpoints (URLs, headers, variable templates, supported protocol versions)
- Optional registry-style extension metadata (
_meta)
Server Cards intentionally omit primitive listings (tools, resources, prompts) — those remain subject to runtime listing via the protocol's standard list operations. They also intentionally omit local installation metadata — see Relationship to the MCP Registry.
Relationship to the MCP Registry
A Server Card describes remote connectivity only. Metadata for locally-installable servers, packages, registries (npm, PyPI, OCI, NuGet, MCPB), runtime hints, command-line arguments, environment variables, lives in the MCP Registry's server.json schema, which is owned by the registry, not by this extension.
Vendors who genuinely need to attach install hints to a Server Card can use namespaced _meta extension metadata, which remains the card's extension point.
Layout
schema.ts # TypeScript source of truth (single file)
schema.json # Generated JSON Schema 2020-12 (do not edit by hand)
scripts/
generate-schema.ts # Generates schema.json from schema.ts
validate-examples.ts # Validates examples/ against the generated schema
examples/
ServerCard/{valid,invalid} # Example Server Card documents
The generated schema.json is checked into the repo so consumers can grab it without running the toolchain.
Working on the schema
npm install
npm run generate # regenerates schema.json from schema.ts
npm run validate # runs all examples through ajv against schema.json
npm run check # asserts schema.json is in sync with schema.ts and tsc passes
npm run format # prettier write
When you change schema.ts, always run npm run generate and commit the updated schema.json in the same commit. CI runs npm run check and will fail if they drift.
Schema URL conventions
The $schema field on every document MUST be a URL of the form:
https://static.modelcontextprotocol.io/schemas/v1/<name>.schema.json
Schema URLs are versioned by their vN segment. Server Card objects are open: the schema does not set additionalProperties: false, and vendor-specific data belongs in the namespaced _meta field. Once v1 is published a breaking revision of the shape would publish a new vN family rather than mutating v1 in place. The v1 shape is still pre-release and card-only — it intentionally does not include the registry-shaped Server / packages types.
Graduation plan
When the SEP is accepted and Server Cards graduate from this experimental extension:
- The contents of
schema.tsin this repo move intoschema/draft/schema.tsofmodelcontextprotocol/modelcontextprotocol. The twoMetaObjectandIcondefinitions inlined here at the bottom ofschema.tsalready exist in the main spec and are dropped from the migration. - The main spec's existing
scripts/generate-schemas.tsregeneratesschema/draft/schema.json(and downstreamdocs/specification/draft/schema.mdx) — no per-extension generator is required there. Both generators leave objects open (noadditionalProperties: false), so the generated shape matches without flag changes. - Published documents update their
$schemato point at the main spec's hosted schema URL (e.g.,https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.jsonserved frommodelcontextprotocol/static). - This repository is archived with a pointer to the relevant section of
schema/draft/schema.tsin the main spec.
The schema.ts in this repo is deliberately structured to be copy-pasted into the main spec's schema/draft/schema.ts with no transformation other than removing the inlined MetaObject / Icon definitions.
References
- SEP-2127: MCP Server Cards (PR)
- SEP-2133: Extensions framework (PR)
- Abandoned core spec PR (superseded by this repo): modelcontextprotocol#2652
- MCP Registry
server.jsonschema