<!-- Provide a brief summary of your changes --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> The following PR: * Deprecates the existing OCI reference parser * Deprecates the existing OCI way of authenticating and accessing the image manifest * Replaces the above by leveraging go-containerregistry * Introduces support for Google Artifact Registry * Enables us to easily add support for other OCI-compliant registries in the future * Introduces better error handling * Introduces custom context timeouts for validation ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> ## 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) - [ ] Documentation update ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [ ] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [ ] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [ ] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> Related to #427 --------- Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
5.2 KiB
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.
Overview
While the generic server.json format 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
- Remote server URL match - Remote server base urls match namespaces
- Restricted registry base urls - Packages are from trusted public registries
_metanamespace restrictions - Restricted topublisherkey 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 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).
For detailed verification requirements for each registry type, see the publishing guide.
Remote Server URL Match
Remote servers must use URLs that match the publisher's domain from their namespace. For example, com.example/server can only use remote URLs on example.com or its subdomains.
Restricted Registry Base URLs
Only trusted public registries are supported. Private registries and alternative mirrors are not allowed.
Supported registries:
- NPM:
https://registry.npmjs.orgonly - PyPI:
https://pypi.orgonly - NuGet:
https://api.nuget.orgonly - Docker/OCI:
- Docker Hub (
docker.io) - GitHub Container Registry (
ghcr.io) - Google Artifact Registry (
*.pkg.dev)
- Docker Hub (
- MCPB:
https://github.comreleases andhttps://gitlab.comreleases 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:
{
"_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_metafield contains publisher-provided custom metadata underio.modelcontextprotocol.registry/publisher-provided - In API responses: The
_metafield is returned as a separate property at the response level (not insideserver.json) and contains registry-managed metadata like:status: Server lifecycle status (active, deprecated, deleted)publishedAt: When the server was first publishedupdatedAt: When the server was last updatedisLatest: Whether this is the latest version
Example: What you publish (server.json)
{
"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
{
"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:
- Inside the
serverobject: Your publisher-provided metadata (preserved from server.json) - 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 for the complete response structure.