modelcontextprotocol/registry
Watch
1
0
Fork
You've already forked registry
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
registry/docs/server-json
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
adam jones e0aecadc24
 refactor: update registry type from 'docker-hub' to 'oci' across seed data (#325) 
Updates the registry type for all Docker Hub packages in the seed data
from `docker-hub` to `oci` to align with the standardized OCI registry
format. This change affects the `registry_type` field and simplifies the
`identifier` field by removing the full Docker Hub URL prefix.

Changes:
- Updated `registry_type` from `docker-hub` to `oci` for all Docker
packages
- Simplified `identifier` field to use just the repository name/path
instead of full URLs
- Maintained `registry_base_url` as `https://docker.io` for all entries

This refactoring improves consistency and aligns with OCI standards
while maintaining backward compatibility through the registry base URL.
2025-08-30 00:12:10 +01:00
..
examples.md refactor: update registry type from 'docker-hub' to 'oci' across seed data (#325) 2025-08-30 00:12:10 +01:00
README.md Add $schema to server.json specification to enable versioning, IDE autocomplete (#308) 2025-08-27 01:30:25 +01:00
registry-schema.json refactor: update registry type from 'docker-hub' to 'oci' across seed data (#325) 2025-08-30 00:12:10 +01:00
repository_references.md Add $schema to server.json specification to enable versioning, IDE autocomplete (#308) 2025-08-27 01:30:25 +01:00
server.schema.json refactor: update registry type from 'docker-hub' to 'oci' across seed data (#325) 2025-08-30 00:12:10 +01:00

README.md

server.json file

There are a variety of use cases where a static representation of an MCP server is necessary:

  • 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
  • Packaged in with the source code of an MCP server, so as to have a structured way to identify a server given just its source code

All of these scenarios (and more) would benefit from an agreed-upon, standardized format that makes it easy to port around and maintain a consistent experience for consumers and developers working with the data. At the end of the day, it's all the same data (or a subset of it). MCP server maintainers should have to manage one copy of this file, and all these use cases can serve that file (or a programmatic derivative/subset of it).

Please note: this is different from the file commonly referred to as mcp.json, which is an MCP client's configuration file for running a specific set of MCP servers. See this issue.

References:

  • server.schema.json - The official JSON schema specification for this representation
  • examples.md - Example manifestations of the JSON schema
  • registry-schema.json - A more constrained version of server.schema.json that the official registry supports

Validation Tools

Two validation tools are provided in the repository's tools/ directory:

  • validate-schemas - Validates that server.schema.json and registry-schema.json are valid JSON Schema documents
  • validate-examples - Validates that all JSON examples in examples.md conform to both schemas

Usage

From the repository root:

Validate JSON Schemas

./tools/validate-schemas.sh

Validate Examples

./tools/validate-examples.sh