Deletes `complete.md` and cleans up the last references to the pre-restructuring docs layout. ## Why `complete.md` goes It is 2,944 lines (31% of all documentation lines in the repo) self-described as *"all documentation from the docs/ directory compiled into a single markdown file"*. But: - **No generator exists.** No make target, no workflow, no script. `grep -rn "complete\.md"` finds **zero** references anywhere in the repo. - **It mirrors a docs tree that no longer exists** — `docs/guides/`, `docs/explanations/`, `docs/concepts/`. - **All 72 of its relative links are broken**, and six of the basenames it references exist nowhere in the repo. - **~14 current docs are missing from it entirely** (`about.mdx`, `authentication.mdx`, `package-types.mdx`, both CHANGELOGs, ...). - **Its `server.json` examples pin the superseded `2025-07-09` schema** (current is `2025-12-11`). The strongest argument is its own last commit. [PR #1278](https://github.com/modelcontextprotocol/registry/pull/1278) closed [issue #767](https://github.com/modelcontextprotocol/registry/issues/767) — a real user-reported CLI flag bug — by editing **only `complete.md`**. A genuine fix landed in a file nobody reads, while the docs a reader would actually find stayed wrong. A generated file with no generator degrades into a trap: authoritative enough that people edit it, with nothing validating it. If the LLM-consumption use case is worth keeping, the right shape is a `make docs-bundle` target plus a `check-docs-bundle` CI job mirroring the existing `check-schema` pattern — happy to do that instead if you would rather keep it. ## Remaining stale references | File | Was | Now | |---|---|---| | `contributing/add-package-registry.md` | Add `docs/guides/publishing/publish-[yourregistry].md`, update `docs/guides/publishing/README.md` | Add a section to `package-types.mdx`. These were the **last live references** to the obsolete `docs/guides/` layout outside `complete.md` | | `administration/maintainer-onboarding.md` | Add them to "Current key maintainers" in README | "Registry Working Group" — the section that actually exists | | `reference/README.md` | Omitted 6 reference docs | Adds `api/extensions.md`, `api/openapi.yaml`, `api/CHANGELOG.md`, `server-json/CHANGELOG.md`, `server-json/CONTRIBUTING.md`, `server-json/draft/` | | `docs/README.md` | Index omitted `community-projects.md` | Listed | | `reference/api/generic-registry-api.md` | `PUT .../versions/{version}` "not implemented by official registry" | It **is** implemented ([edit.go:36](https://github.com/modelcontextprotocol/registry/blob/main/internal/api/handlers/v0/edit.go#L36)), and `official-registry-api.md` already lists it as an admin endpoint | | `reference/api/official-registry-api.md` | Omitted 3 registered routes | Adds `POST /v0.1/validate` (which `mcp-publisher validate` calls), `GET /v0.1/ping`, `GET /v0.1/version`, and notes these plus `/health` are absent from `openapi.yaml` | | `server-json/official-registry-requirements.md` | Per-registry verification → `quickstart.mdx` | → `package-types.mdx`, which has an Ownership Verification section per registry | | `design/design-principles.md` | Sections 1,2,3,4,**6**,7 | Renumbered 1–6 | | `contributing/releasing.md` | Steps 1,2,3,**5**,6 | Renumbered 1–5 | I left the sibling `DELETE` claim in `generic-registry-api.md` alone — it is accurate, no DELETE route is registered (the `http.MethodDelete` hit in `server.go` is CORS config, not a route). ## Staleness banners rather than rewrites **`design/tech-architecture.md`** is substantially fictional. Rather than a vague "may be outdated", the banner lists what I verified is wrong: - Describes Helm-chart deployment; the registry is a plain `Deployment` ([registry.go:65](https://github.com/modelcontextprotocol/registry/blob/main/deploy/pkg/k8s/registry.go#L65)). Helm is used only for third-party components. - Diagram shows a `StatefulSet` on port **27017** — MongoDB's port. The DB is PostgreSQL on 5432 via the CloudNativePG operator. - Documents a `verify-domain` challenge flow (`POST /verify-domain`, `/verify-domain/check`, server-issued tokens) that **was never built**. - Documents `/admin/*` routes that are not registered. - Says the DB stores user auth state and DNS verification records; only `servers` and `server_extensions` tables exist. **`design/roadmap.md`** still says "Phase 1: MVP/Go-Live (Current Focus)" ~11 months after launch. I added a dated note rather than inventing a current phase — that is a working-group call. ## Verification All **101** remaining relative links across every `.md`/`.mdx` in the repo resolve. The only two non-resolving matches are the intentional `[project-name](link)` template placeholder and the moderation link fixed in #1518. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
3.1 KiB
Generic Registry API Specification
A standardized RESTful HTTP API for MCP registries to provide consistent endpoints for discovering and retrieving MCP servers.
Also see:
- For authentication and authorization, see the registry authorization specification.
Browse the Complete API Specification
📋 View the full API specification interactively: Open openapi.yaml in an OpenAPI viewer like Stoplight Elements.
The official registry has some more endpoints and restrictions on top of this. See the official registry API spec for details.
Quick Reference
Core Endpoints
GET /v0.1/servers- List all servers with paginationGET /v0.1/servers/{serverName}/versions- List all versions of a serverGET /v0.1/servers/{serverName}/versions/{version}- Get specific version of server. Use the special versionlatestto get the latest version.POST /v0.1/publish- Publish new server (optional, registry-specific authentication)PUT /v0.1/servers/{serverName}/versions/{version}- Update specific server version (optional; the official registry implements this as an admin endpoint)DELETE /v0.1/servers/{serverName}/versions/{version}- Delete specific server version (optional, not implemented by official registry)PATCH /v0.1/servers/{serverName}/versions/{version}/status- Update server version status (optional)PATCH /v0.1/servers/{serverName}/status- Update status for all versions (optional)
Server names and version strings should be URL-encoded in paths.
Authentication
No authentication required by default. Subregistries may optionally require authentication following the registry authorization specification.
Content Type
All requests and responses use application/json
Pagination
List endpoints use cursor-based pagination for efficient, stable results.
Usage
- Initial request: Omit the
cursorparameter - Subsequent requests: Use the
nextCursorvalue from the previous response - End of results: When
nextCursoris null or empty, there are no more results
Important: Always treat cursors as opaque strings. Never manually construct or modify cursor values.
Basic Example: List Servers
curl https://registry.example.com/v0.1/servers?limit=10
{
"servers": [
{
"server": {
"name": "io.modelcontextprotocol/filesystem",
"description": "Filesystem operations server",
"version": "1.0.2"
},
"_meta": {
"io.modelcontextprotocol.registry/official": {
"status": "active",
"publishedAt": "2025-01-01T10:30:00Z",
"isLatest": true
}
}
}
],
"metadata": {
"count": 10,
"nextCursor": "com.example/my-server:1.0.0"
}
}
For complete endpoint documentation, view the OpenAPI specification in a schema viewer.