| Filename | Latest commit message | Latest commit date |
|---|---|---|
6a2e5d1b27<!-- Provide a brief summary of your changes --> ## Motivation and Context This is in support of https://github.com/modelcontextprotocol/registry/issues/159, to make it easier, I hope. My team noticed some differences in the JSON schema, most notably the "choices" property was missing. I tried to write a tool to do this but slowed down since I am not experienced with Go. This is a first pass, maybe someone else can finish the tooling. I restructured the JSON schema to break out child objects like the YAML file, and brought the descriptions and example into sync. The only differences are two extra properties in the YAML which are computed by the server: - `VersionDetail.is_latest` is not present in the JSON schema, computed by the registry based on https://github.com/modelcontextprotocol/registry/issues/158 - `Server.id` is not present in the JSON schema, generated by the registry The idea is the a tool could look at ServerDetail in the YAML and then generate the schema.json with minimal fix-ups (add a root title, remove `VersionDetail.is_latest` and `Server.id`. ~Question for @tadasant - should `VersionDetail.release_date` be in the JSON schema? I think _no_ (and let it be computed) but it's there right now.~ - aligned with https://github.com/modelcontextprotocol/registry/pull/167 and removed ## How Has This Been Tested? I have tested the JSON schema against the sample server.json in the repo (files and markdown blocks). ## Breaking Changes None. ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] 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 ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [x] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [x] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [x] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> |
||
| .. | ||
| examples.md | ||
| README.md | ||
| schema.json | ||
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-knownendpoint - 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:
- schema.json - The official JSON schema specification for this representation
- examples.md - Example manifestations of the JSON schema