| Filename | Latest commit message | Latest commit date |
|---|---|---|
a5f417b6f5Closes #155 The "generalized" `server.json` is the one that can be used in a variety of situations: - Discoverability on a centralized registry (i.e. our official Registry work) - Discoverability on a decentralized .well-known endpoint - As a response to an initialization call, so the client knows information about the MCP server to which it is connecting - As an input into crafting a [DXT file](https://www.anthropic.com/engineering/desktop-extensions) - Packaged in with the source code of an MCP server, so as to have a structured way context Of these, the official Registry is but one use case. The Registry has a unique set of concerns for which we are optimizing, like whitelisting of specific registries we trust to host MCP server source code for the public community (`npm`, `pypi`, etc). It is not necessary to have such a constraint for the generalized server.json, which may be used in, for example, an internal context where such a validation doesn't make sense. So I've done the following at a high level: - Renamed the prior `schema.json` to be `registry-schema.json` - Introduced a more generic `schema.json` to serve as the schema for the generalized `server.json` - Refactored `registry-schema.json` to be simply a constraint on the base `schema.json` I made a few small changes in this transition: - Removed `gitlab` as an option in `repository.source` for `registry-schema.json`. I'm fine going live with just GitHub support; would be happy to take a contribution from e.g. Gitlab employees or a motivated Gitlab customer to expand anytime. - Removed `homebrew` as an option in `packages.registry_name`; never really made sense, not a place where folks are publishing MCP servers - Added `docker` to `packages.runtime_hint`; was just a missing oversight - Gave both schemas a global `$id` ~- Removed `release_date` from both schemas. Certainly not something that makes sense for the generalized schema. It actually doesn't make sense for the Registry schema either, because this is the server.json that _users will submit_, i.e. the _input_ into the Registry publication API. `release_date` will be a piece of _output_ metadata. The Registry API will be free to append such extra metadata for GET /:id requests of servers, and the data can be present in the OpenAPI spec, but it does not need to be in the registry-server.json JSON schema.~ - Note this is no longer in this PR; rebased on #168 which included it - Removed unnecessary enums from the generalized `schema.json` |
||
| .. | ||
| server-json | ||
| api_examples.md | ||
| architecture.md | ||
| design_principles.md | ||
| faq.md | ||
| MCP Developers Summit 2025 - Registry Talk Slides.pdf | ||
| new_package_registry.md | ||
| openapi.yaml | ||
| README.md | ||
| roadmap.md | ||
Official Registry Documentation
Project Documentation
design_principles.md - Core constraints and principles guiding the registry design
faq.md - Frequently asked questions about the MCP Registry
roadmap.md - High-level roadmap for the MCP Registry development
MCP Developers Summit 2025 - Registry Talk Slides.pdf - Slides from a talk given at the MCP Developers Summit on May 23, 2025, with an up-to-date vision of how we are thinking about the official registry.
API & Technical Specifications
openapi.yaml - OpenAPI specification for the official registry API
api_examples.md - Examples of what data will actually look like coming from the official registry API
architecture.md - Technical architecture, deployment strategies, and data flows
server.json README - description of the server.json purpose and schema
new_package_registry.md - steps to add a new package registry for local server packages