• TypeScript 100%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Tadas Antanavicius 72793bb203
docs(discovery): drop displayName from MCP Catalog entries (#14) (#39)
## 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>
2026-07-13 21:23:13 +02:00
.github/workflows Bootstrap repo with TypeScript source-of-truth and generated JSON Schema 2026-04-27 19:47:01 +00:00
docs docs(discovery): drop displayName from MCP Catalog entries (#14) (#39) 2026-07-13 21:23:13 +02:00
examples/ServerCard Make the extension card-only: remove registry Server/package types (#28) 2026-06-18 19:11:55 +02:00
scripts Make the extension card-only: remove registry Server/package types (#28) 2026-06-18 19:11:55 +02:00
.gitignore Bootstrap repo with TypeScript source-of-truth and generated JSON Schema 2026-04-27 19:47:01 +00:00
AGENTS.md docs: add AGENTS.md (CLAUDE.md symlink) for AI coding agents (#20) 2026-06-08 08:16:20 -07:00
CLAUDE.md docs: add AGENTS.md (CLAUDE.md symlink) for AI coding agents (#20) 2026-06-08 08:16:20 -07:00
LICENSE Initial commit 2026-04-27 21:19:27 +02:00
package-lock.json Bump vm2 in the npm_and_yarn group across 1 directory 2026-05-08 14:45:46 +00:00
package.json Bootstrap repo with TypeScript source-of-truth and generated JSON Schema 2026-04-27 19:47:01 +00:00
README.md docs: drop references to the MCP initialization handshake (SEP-2575) (#37) 2026-06-27 08:37:45 +02:00
schema.json docs: drop references to the MCP initialization handshake (SEP-2575) (#37) 2026-06-27 08:37:45 +02:00
schema.ts docs: drop references to the MCP initialization handshake (SEP-2575) (#37) 2026-06-27 08:37:45 +02:00
tsconfig.json Bootstrap repo with TypeScript source-of-truth and generated JSON Schema 2026-04-27 19:47:01 +00:00

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, optional title / 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:

  1. The contents of schema.ts in this repo move into schema/draft/schema.ts of modelcontextprotocol/modelcontextprotocol. The two MetaObject and Icon definitions inlined here at the bottom of schema.ts already exist in the main spec and are dropped from the migration.
  2. The main spec's existing scripts/generate-schemas.ts regenerates schema/draft/schema.json (and downstream docs/specification/draft/schema.mdx) — no per-extension generator is required there. Both generators leave objects open (no additionalProperties: false), so the generated shape matches without flag changes.
  3. Published documents update their $schema to point at the main spec's hosted schema URL (e.g., https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json served from modelcontextprotocol/static).
  4. This repository is archived with a pointer to the relevant section of schema/draft/schema.ts in 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