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`
40 lines
No EOL
999 B
JSON
40 lines
No EOL
999 B
JSON
{
|
|
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
"$id": "https://modelcontextprotocol.io/schemas/draft/2025-07-09/registry-server.json",
|
|
"title": "MCP Server Detail - Registry Schema",
|
|
"description": "Registry-specific constraints for MCP server representation. Extends the base schema with additional validation rules.",
|
|
"$ref": "https://modelcontextprotocol.io/schemas/draft/2025-07-09/server.json",
|
|
"properties": {
|
|
"repository": {
|
|
"properties": {
|
|
"source": {
|
|
"enum": [
|
|
"github"
|
|
]
|
|
}
|
|
}
|
|
},
|
|
"packages": {
|
|
"items": {
|
|
"properties": {
|
|
"registry_name": {
|
|
"enum": [
|
|
"npm",
|
|
"pypi",
|
|
"docker",
|
|
"nuget"
|
|
]
|
|
},
|
|
"runtime_hint": {
|
|
"enum": [
|
|
"npx",
|
|
"uvx",
|
|
"docker",
|
|
"dnx"
|
|
]
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
} |