Watch

adam jones 2e7108d366

Big docs tidy up in preparation for launch (#364 )

## Motivation and Context
Docs currently don't have very clear organisation, and don't explain
core flows.

This fixes #89 (although we still might want to push these to
`https://modelcontextprotocol.io/docs/`), based on the plan there.

One minor change from that plan is that I merged tutorials and guides,
because they ended up basically being duplicates which I thought would
be annoying for us to keep in sync. Additionally in the Diátaxis
framework, tutorials and guides are separated by whether they are
focused on acquisition of skills (e.g. in a learning environment) or
application of skills (e.g. in a work environment). I expect the
registry to be something that will be used occasionally in a work
environment, rather than a fundamental 'learnable' skill so I think it's
reasonable not to have tutorials and fold these into guides.

## How Has This Been Tested?
- Read through all these updated docs
- Unit and integration tests (that previously used examples.md and use
the schema) working
- Ran `npx markdown-link-check .` to check all the links work

## Breaking Changes
Links to old docs will break, but I don't think there are any. All
internal links have been checked and updated.

## 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)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update

2025-09-07 10:44:42 +01:00

2.4 KiB

Raw Blame History

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
_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 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.org only
PyPI: https://pypi.org only
NuGet: https://api.nuget.org only
Docker/OCI: https://docker.io only
MCPB: https://github.com releases and https://gitlab.com releases only

`_meta` Namespace Restrictions

The _meta field is restricted to the publisher key only during publishing. This _meta.publisher extension is currently limited to 4KB.

Registry metadata is added automatically and cannot be overridden.

2.4 KiB Raw Blame History