bb84ea69e8(Updated auto-generated PR description from @tadasant / Claude on Feb 22, 2026) ## Motivation and Context Fixes #637 Server lifecycle management (deprecation and yanking) is a standard requirement for package registries. Use cases like rebranding, security vulnerabilities, and end-of-life servers demand the ability to mark servers as deprecated or deleted, with optional messaging to guide consumers toward alternatives. ## Changes ### New API endpoints - **`PATCH /v0/servers/{serverName}/versions/{version}/status`** — Update the lifecycle status of a single server version - **`PATCH /v0/servers/{serverName}/status`** — Update the lifecycle status of all versions of a server in a single transaction Both endpoints accept: ```json { "status": "active|deprecated|deleted", "statusMessage": "Optional message (max 500 chars) explaining the change" } ``` ### New CLI command - **`mcp-publisher status <serverName> [version]`** — Update server lifecycle status from the command line - `--status` (required): `active`, `deprecated`, or `deleted` - `--message`: Optional status message - `--all-versions`: Apply to all versions of the server (replaces the `<version>` argument) ### API response changes `RegistryExtensions` now includes two new fields: - `statusChangedAt` — Timestamp of the last status change - `statusMessage` — Optional free-form message (e.g., deprecation reason, migration guidance) ### List endpoint changes - New `include_deleted` query parameter on `GET /v0/servers` — defaults to `false`, hiding deleted servers from listings - When `updated_since` is provided, `include_deleted` is automatically set to `true` for incremental sync ### Database - Migration `013_add_status_fields.sql`: Adds `status_changed_at` (NOT NULL, initialized from `published_at`) and `status_message` columns to the `servers` table ### Design decisions (from review discussion) - **Dedicated status endpoints** rather than overloading the existing edit endpoint - **Bidirectional status transitions** — all transitions between `active`, `deprecated`, and `deleted` are allowed - **`statusMessage` as free-form text** — no structured `nextName` or `alternativeUrl` fields (per maintainer feedback, to avoid complexity around chaining, trust transfer, etc.) - **Publish permission** grants status change access (not limited to admin/edit) - **Status message auto-cleared** when transitioning back to `active` Good, now I have the full picture. Here's the addendum: ### Consumer-facing API changes The new status fields live inside `_meta["io.modelcontextprotocol.registry/official"]` on every `ServerResponse`. This is the existing `RegistryExtensions` object — two new fields are added alongside the existing ones: **Before:** ```json { "server": { "name": "com.example/my-server", "...": "..." }, "_meta": { "io.modelcontextprotocol.registry/official": { "status": "active", "publishedAt": "2025-06-01T00:00:00Z", "updatedAt": "2025-06-15T00:00:00Z", "isLatest": true } } } ``` **After:** ```json { "server": { "name": "com.example/my-server", "...": "..." }, "_meta": { "io.modelcontextprotocol.registry/official": { "status": "deprecated", "statusChangedAt": "2026-02-01T12:00:00Z", "statusMessage": "Deprecated in favor of com.example/my-server-v2", "publishedAt": "2025-06-01T00:00:00Z", "updatedAt": "2026-02-01T12:00:00Z", "isLatest": true } } } ``` | New field | Type | Present when | |-----------|------|-------------| | `statusChangedAt` | `string` (RFC3339) | Always — initialized to `publishedAt` for existing records | | `statusMessage` | `string` (max 500 chars) | Only when set — `null`/omitted for active servers (auto-cleared on transition to active) | These fields appear on **every endpoint that returns a `ServerResponse`**: `GET /v0/servers`, `GET /v0/servers/{name}`, `GET /v0/servers/{name}/versions/{version}`, and the new PATCH status endpoints. ### List endpoint filtering `GET /v0/servers` gains an `include_deleted` query parameter: | Scenario | Behavior | |----------|----------| | No `include_deleted` param | Deleted servers hidden (default `false`) | | `include_deleted=true` | Deleted servers included in results | | `updated_since` provided | `include_deleted` forced to `true` for incremental sync | ## How Has This Been Tested? - Unit tests for status handler (`status_test.go`) covering status transitions, permission checks, validation errors, and the all-versions endpoint - Unit tests for the CLI command (`status_test.go`) - Integration with existing server/edit handler tests - Database layer tests for the new status update and query methods - Tested locally with `make dev-compose` ## Types of changes - [x] New feature (non-breaking change which adds functionality) ## Checklist - [x] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [x] My code follows the repository's style guidelines - [x] New and existing tests pass locally - [x] I have added appropriate error handling - [x] I have added or updated documentation as needed ## Open items from review - [ ] `include_deleted` silent override: When `updated_since` is provided and `include_deleted=false` is explicitly passed, should return a 400 error rather than silently overriding ([thread](https://github.com/modelcontextprotocol/registry/pull/893#discussion_r2100879360)) — agreed upon but may not yet be implemented
76 lines
3.1 KiB
Markdown
76 lines
3.1 KiB
Markdown
# 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](./registry-authorization.md).
|
|
|
|
## Browse the Complete API Specification
|
|
|
|
**📋 View the full API specification interactively**: Open [openapi.yaml](./openapi.yaml) in an OpenAPI viewer like [Stoplight Elements](https://elements-demo.stoplight.io/?spec=https://raw.githubusercontent.com/modelcontextprotocol/registry/refs/heads/main/docs/reference/api/openapi.yaml).
|
|
|
|
The official registry has some more endpoints and restrictions on top of this. See the [official registry API spec](./official-registry-api.md) for details.
|
|
|
|
## Quick Reference
|
|
|
|
### Core Endpoints
|
|
- **`GET /v0.1/servers`** - List all servers with pagination
|
|
- **`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)
|
|
- **`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](./registry-authorization.md).
|
|
|
|
### Content Type
|
|
All requests and responses use `application/json`
|
|
|
|
### Pagination
|
|
List endpoints use cursor-based pagination for efficient, stable results.
|
|
|
|
#### Usage
|
|
1. **Initial request**: Omit the `cursor` parameter
|
|
2. **Subsequent requests**: Use the `nextCursor` value from the previous response
|
|
3. **End of results**: When `nextCursor` is 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
|
|
|
|
```bash
|
|
curl https://registry.example.com/v0.1/servers?limit=10
|
|
```
|
|
|
|
```json
|
|
{
|
|
"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.
|