Adds support for the Quay.io container registry to the OCI validator. This allows MCP servers hosted on Quay.io to be registered and validated by the official registry. ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> Quay.io is a major, trusted public OCI registry widely used by the cloud-native and open-source communities. Currently, attempting to publish a server using a Quay image results in an unsupported OCI registry error. This change enables developers to use Quay.io as a first-class hosting option for their MCP server images. ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> - **Unit Tests:** Updated `internal/validators/registries/oci_test.go` to transition Quay.io from a rejected test case to an allowed one. - **Pattern Matching:** Verified that the allowlist correctly handles both specific image identifiers and general pattern matching for the `quay.io` host. - **Local Validation:** Ran `make check` to ensure no regressions in the existing OCI validation logic. ## Breaking Changes <!-- Will users need to update their code or configurations? --> No. This is an additive change that expands the allowlist of supported registries. Existing configurations are unaffected. ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Documentation update ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [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 ## Additional context <!-- Add any other context, implementation notes, or design decisions --> The implementation follows the existing pattern for OCI registries: 1. Added a `RegistryURLQuay` constant to `pkg/model` for consistency. 2. Hardcoded `quay.io` into the `allowedOCIRegistries` map in the validator to minimize architectural complexity. 3. Updated all relevant documentation files (`package-types.mdx`, `generic-server-json.md`, and `official-registry-requirements.md`) to ensure the source of truth is updated across the project. 4. Validation remains scoped to public images; no private registry authentication was added for this host. Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info> Co-authored-by: Radoslav Dimitrov <radoslav@stacklok.com>
130 lines
5 KiB
Markdown
130 lines
5 KiB
Markdown
# Official Registry Server.json Requirements
|
|
|
|
This document describes the additional requirements and validation rules that apply when publishing to the official MCP Registry at `registry.modelcontextprotocol.io`.
|
|
|
|
For step-by-step publishing instructions, see the [publishing guide](../../modelcontextprotocol-io/quickstart.mdx).
|
|
|
|
## Overview
|
|
|
|
While the [generic server.json format](./generic-server-json.md) defines the base specification, the official registry enforces additional validation to ensure:
|
|
|
|
- **Namespace authentication** - Servers are published under appropriate namespaces
|
|
- **Package ownership verification** - Publishers actually control referenced packages
|
|
- **Restricted registry base urls** - Packages are from trusted public registries
|
|
- **`_meta` namespace restrictions** - Restricted to `publisher` key only
|
|
|
|
## Namespace Authentication
|
|
|
|
Publishers must prove ownership of their namespace. For example to publish to `com.example/server`, the publisher must prove they own the `example.com` domain.
|
|
|
|
See the [publishing guide](../../modelcontextprotocol-io/quickstart.mdx) for authentication details for GitHub and domain namespaces.
|
|
|
|
## Package Ownership Verification
|
|
|
|
All packages must include metadata proving the publisher owns them. This prevents impersonation and ensures authenticity (see more reasoning in [#96](https://github.com/modelcontextprotocol/registry/issues/96)).
|
|
|
|
For detailed verification requirements for each registry type, see the [publishing guide](../../modelcontextprotocol-io/quickstart.mdx).
|
|
|
|
## Restricted Registry Base URLs
|
|
|
|
Only trusted public registries are supported. Private registries and alternative mirrors are not allowed.
|
|
|
|
**Supported registries:**
|
|
- **NPM**: `https://registry.npmjs.org` only
|
|
- **PyPI**: `https://pypi.org` only
|
|
- **NuGet**: `https://api.nuget.org/v3/index.json` only
|
|
- **Docker/OCI**:
|
|
- Docker Hub (`docker.io`)
|
|
- GitHub Container Registry (`ghcr.io`)
|
|
- Quay.io (`quay.io`)
|
|
- Google Artifact Registry (`*.pkg.dev`)
|
|
- Azure Container Registry (`*.azurecr.io`)
|
|
- Microsoft Container Registry (`mcr.microsoft.com`)
|
|
- **MCPB**: `https://github.com` releases and `https://gitlab.com` releases only
|
|
|
|
## `_meta` Namespace Restrictions
|
|
|
|
The `_meta` field in `server.json` allows publishers to include custom metadata alongside their server definitions.
|
|
|
|
### Publisher-Provided Metadata
|
|
|
|
When publishing to the official registry, **only data under the specific key `io.modelcontextprotocol.registry/publisher-provided` will be preserved**. Any other keys in the `_meta` object are silently dropped during publishing and will not be stored or returned by the registry.
|
|
|
|
**Example:**
|
|
|
|
```jsonc
|
|
{
|
|
"_meta": {
|
|
"io.modelcontextprotocol.registry/publisher-provided": {
|
|
"tool": "ci-publisher",
|
|
"version": "1.0.0",
|
|
"custom_data": "your data here"
|
|
},
|
|
"some.other.key": {
|
|
// This will be dropped and not preserved
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
**Size limit:** The publisher-provided extension is limited to 4KB (4096 bytes) of JSON. If the marshaled JSON exceeds this limit, publishing will fail with an error indicating the actual size.
|
|
|
|
### Registry API Metadata vs server.json Metadata
|
|
|
|
The `_meta` field in `server.json` is **different** from the `_meta` field returned in registry API responses:
|
|
|
|
- **In `server.json`**: The `_meta` field contains publisher-provided custom metadata under `io.modelcontextprotocol.registry/publisher-provided`
|
|
- **In API responses**: The `_meta` field is returned as a separate property at the response level (not inside `server.json`) and contains registry-managed metadata like:
|
|
- `status`: Server lifecycle status (active, deprecated, deleted)
|
|
- `publishedAt`: When the server was first published
|
|
- `updatedAt`: When the server was last updated
|
|
- `isLatest`: Whether this is the latest version
|
|
|
|
**Example: What you publish (server.json)**
|
|
|
|
```jsonc
|
|
{
|
|
"name": "io.github.example/my-server",
|
|
"version": "1.0.0",
|
|
"description": "My MCP server",
|
|
// ... other fields ...
|
|
"_meta": {
|
|
"io.modelcontextprotocol.registry/publisher-provided": {
|
|
"tool": "ci-publisher",
|
|
"version": "2.0.0"
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
**Example: What the registry API returns**
|
|
|
|
```jsonc
|
|
{
|
|
"server": {
|
|
"name": "io.github.example/my-server",
|
|
"version": "1.0.0",
|
|
"description": "My MCP server",
|
|
// ... other fields ...
|
|
"_meta": {
|
|
"io.modelcontextprotocol.registry/publisher-provided": {
|
|
"tool": "ci-publisher",
|
|
"version": "2.0.0"
|
|
}
|
|
}
|
|
},
|
|
"_meta": {
|
|
// Registry-managed metadata at response level
|
|
"status": "active",
|
|
"publishedAt": "2024-01-15T10:30:00Z",
|
|
"updatedAt": "2024-01-15T10:30:00Z",
|
|
"isLatest": true
|
|
}
|
|
}
|
|
```
|
|
|
|
Notice how the registry API response has **two** `_meta` fields:
|
|
1. Inside the `server` object: Your publisher-provided metadata (preserved from server.json)
|
|
2. At the response level: Registry-managed metadata (automatically added by the registry)
|
|
|
|
Registry-managed metadata cannot be set or overridden by publishers. See the [API documentation](../api/generic-registry-api.md) for the complete response structure.
|