| Filename | Latest commit message | Latest commit date |
|---|---|---|
c3b72ef3a6<!-- Provide a brief summary of your changes --> The changes are intended to create validators for all the free-form fields. Please find the details of the validation of different field below. - Repository.Source: only github and gitlab is accepted. - Repository.Url - It should be a valid github or gitlab URL. Created regex for both. - Server.Name - Max 200 char can be there. Reverse domain name verification is part of another PR (not owned by me). - Package.Name - Max 200 char and no spaces. - Server.Description - Max 100 char. - Remote.Url - It should be valid URL. ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> The motivation was to make the code clean and add base code for more validator for different objects like Repository etc. https://github.com/modelcontextprotocol/registry/issues/97 ## How Has This Been Tested? It's tested via UTs. Added UT's for all the validations. ## Breaking Changes Yes ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [x] Breaking change (fix or feature that would cause existing functionality to change) - [ ] 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) - [ ] My code follows the repository's style guidelines - [x] New and existing tests pass locally - [x] I have added appropriate error handling - [ ] I have added or updated documentation as needed Co-authored-by: Avish Porwal <avishporwal@microsoft.com> Co-authored-by: Adam Jones <adamj+git@anthropic.com> |
||
| .. | ||
| examples.md | ||
| README.md | ||
| registry-schema.json | ||
| repository_references.md | ||
| server.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:
- 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.jsonthat the official registry supports
Validation Tools
Two validation tools are provided in the repository's tools/ directory:
- validate-schemas - Validates that
server.schema.jsonandregistry-schema.jsonare valid JSON Schema documents - validate-examples - Validates that all JSON examples in
examples.mdconform to both schemas
Usage
From the repository root:
Validate JSON Schemas
./tools/validate-schemas.sh
Validate Examples
./tools/validate-examples.sh