docs: remove stale complete.md and fix remaining stale references (#1522)

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](#1278)
closed [issue
#767](#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>

Author: rdimitrov

complete.md

@@ -17,3 +17,4 @@ The MCP registry provides MCP clients with a list of MCP servers, like an app st
 - 📖 [Reference](./reference/) - Technical specifications
 - 🔧 [Contributing guides](./contributing/) - How to contribute
 - 🔒 [Administration](./administration/) - Admin operations
+- 🤝 [Community projects](./community-projects.md) - Notable registry-related work from the community

docs/README.md

@@ -16,7 +16,7 @@ When onboarding a new maintainer, complete the following steps:
 
 ### 3. README.md
 
-- [ ] Add them to the "Current key maintainers" section in [README.md](../../README.md)
+- [ ] Add them to the "Registry Working Group" section in [README.md](../../README.md)
 
 ### 4. Discord
 

docs/administration/maintainer-onboarding.md

@@ -51,6 +51,5 @@ These steps may evolve as additional validations or details are discovered and m
       - Add corresponding unit tests: `internal/validators/registries/yourregistry_test.go`
       - Register your validator in `internal/validators/validators.go`
    - Update the publishing documentation:
-      - Add a new publishing guide: `docs/guides/publishing/publish-[yourregistry].md`, following the pattern of existing publishing guides (e.g., `publish-npm.md`, `publish-pypi.md`)
-      - Include instructions on how to prepare packages for your registry, including any specific validation requirements
-      - Update `docs/guides/publishing/README.md` to reference your new publishing guide
+      - Add a section for your registry to `docs/modelcontextprotocol-io/package-types.mdx`, following the pattern of the existing registries (npm, PyPI, NuGet, ...)
+      - Include instructions on how to prepare packages for your registry, and an `### Ownership Verification` subsection describing the validation your registry requires

docs/contributing/add-package-registry.md

@@ -5,8 +5,8 @@
 1. **Go to GitHub**: Navigate to https://github.com/modelcontextprotocol/registry/releases
 2. **Click "Draft a new release"**
 3. **Choose a tag**: Click "Choose a tag" and type a new semantic version that follows the last one available (e.g., `v1.0.0`)
-5. **Generate notes**: Click "Generate release notes" to auto-populate the name and description
-6. **Publish**: Click "Publish release"
+4. **Generate notes**: Click "Generate release notes" to auto-populate the name and description
+5. **Publish**: Click "Publish release"
 
 The release workflow will automatically:
 - Build binaries for 6 platforms (Linux, macOS, Windows × amd64, arm64)

docs/contributing/releasing.md

@@ -25,13 +25,13 @@ The registry serves as the authoritative metadata repository for publicly-availa
 - Use mechanisms like DNS verification, OAuth to provide base layer of authentication and trust
 - Implement rate limiting, field validation, and blacklisting to prevent abuse
 
-## 6. Reusable, Extensible Shapes; Not Infrastructure
+## 5. Reusable, Extensible Shapes; Not Infrastructure
 
 - API shapes (OpenAPI, server.json) designed for reuse
 - Enable private/internal registries using same formats
 - Don't mandate infrastructure reuse - focus on interface compatibility
 
-## 7. Progressive Enhancement
+## 6. Progressive Enhancement
 
 - Start with MVP that provides immediate value
 - Build foundation that supports future features

docs/design/design-principles.md

@@ -6,9 +6,15 @@ This roadmap may occasionally drift out of date. Please review [Issues](https://
 
 ## Current Status
 
+> [!NOTE]
+> **The phase labelling below is out of date as of 2026-08-10.** The registry launched in preview on
+> 2025-09-08 and the v0.1 API entered a freeze on 2025-10-24, so "Go-Live" has already happened. The
+> phases are retained for historical context. See
+> [Issues](https://github.com/modelcontextprotocol/registry/issues) for current work.
+
 The initial version of the MCP Registry is actively being developed. The initial focus is on delivering a REST API to which server creators can publish, and aggregator/marketplace consumers can ETL.
 
-## Phase 1: MVP/Go-Live (Current Focus)
+## Phase 1: MVP/Go-Live
 
 See the [go-live blocker issues](https://github.com/modelcontextprotocol/registry/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22go-live%20blocker%22).
 

docs/design/roadmap.md

@@ -1,5 +1,26 @@
 # MCP Registry Technical Architecture
 
+> [!WARNING]
+> **This document has drifted from the shipped system and is kept as a design record.**
+> For the architecture as deployed, see [deploy/README.md](../../deploy/README.md); for the API as
+> implemented, see the [API reference](../reference/api/official-registry-api.md).
+>
+> Known inaccuracies below, as of 2026-08-10:
+> - The registry is not deployed via a Helm chart. It is a plain Kubernetes `Deployment` created by
+>   Pulumi; Helm is used only for third-party components (ingress-nginx, cert-manager,
+>   cloudnative-pg, k8up, monitoring).
+> - The database diagram shows a `StatefulSet` on port `27017` (MongoDB). The database is PostgreSQL
+>   on `5432`, provisioned by the CloudNativePG operator.
+> - The DNS verification sequence (`mcp verify-domain`, `POST /verify-domain`,
+>   `POST /verify-domain/check`, server-issued challenge tokens) describes a design that was never
+>   built. The shipped flow signs a timestamp with the operator's key and posts it to
+>   `POST /v0/auth/dns`, with the public key published in a `v=MCPv1; k=...; p=...` TXT record.
+> - No `/admin/*` routes exist. Admin actions use the regular server endpoints with an
+>   admin-permissioned token.
+> - The CLI is `mcp-publisher`, not `mcp`, and publishing posts to `/v0/publish`.
+> - The database stores servers and server extensions only; it holds no user authentication state
+>   and no DNS verification records.
+
 This document describes the technical architecture of the MCP Registry, including system components, deployment strategies, and data flows.
 
 ## System Overview

docs/design/tech-architecture.md

@@ -7,11 +7,17 @@ Technical specifications and quick lookups for the MCP Registry.
 - [Generic Registry API](./api/generic-registry-api.md)
 - [Registry Authorization](./api/registry-authorization.md)
 - [Official Registry API](./api/official-registry-api.md)
+- [API Extensions](./api/extensions.md) - The `_meta` extension namespaces
+- [OpenAPI Specification](./api/openapi.yaml)
+- [API Changelog](./api/CHANGELOG.md)
 
 ## server.json Reference
 
 - [Generic server.json Format](./server-json/generic-server-json.md)
 - [Official Registry Requirements](./server-json/official-registry-requirements.md)
+- [Schema Changelog](./server-json/CHANGELOG.md)
+- [Schema Change Process](./server-json/CONTRIBUTING.md) - How to propose a schema change
+- [Draft Schema](./server-json/draft/) - The in-progress next schema version
 
 ## CLI Reference
 

docs/reference/README.md

@@ -18,7 +18,7 @@ The official registry has some more endpoints and restrictions on top of this. S
 - **`GET /v0.1/servers/{serverName}/versions`** - List all versions of a server
 - **`GET /v0.1/servers/{serverName}/versions/{version}`** - Get specific version of server. Use the special version `latest` to 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, not implemented by official registry)
+- **`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)