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 07d353ba92
 Update examples.md for more realism (#332) 
## Summary
- Updates all server.json examples to use `io.github` namespace instead
of `com.github`
- Fixes validator test case to use proper domain format
- Aligns with standard reverse domain name convention for GitHub-hosted
projects

This change improves consistency across documentation examples and
follows established naming conventions.
2025-09-01 22:58:55 +01:00
..
examples.md Update examples.md for more realism (#332) 2025-09-01 22:58:55 +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 Implement flattened _meta format for server extensions (#331) 2025-09-01 19:27:23 +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