| Filename | Latest commit message | Latest commit date |
|---|---|---|
8d7e471fd3<!-- Provide a brief summary of your changes -->
This PR serves as a placeholder and brings together all of the changes
related to supporting vendor extensions passed through the API. The idea
is to have a single place to track and review the work as it comes
together (even if it’s still a bit of a work in progress).
**The changes in this PR cover:**
* Updates on the data model
* Updates on both databases (in-memory and postgresql), added a new
table to PSQL for tracking the extensions leaving the server table only
for the clean server.json properties
* Updates the seed.json file (thus the big line change)
* Adds a seed-migrate tool to help migrating an existing seed file to
the new format
* Updates the seed import mechanism to support this
* Updates the existing tests - unit, integration and validation tests
* Adds the publish handler to the OpenAPI spec (it was missing)
* Fixes linting errors
* Updates on the API side on (publish, list, get) to support the new
format of `ServerResponse` -
```
{
"server": {},
"x-io.modelcontextprotocol.registry": {}, /*not available for publish since this gets populated by the registry*/
"x-publisher": {}
}
```
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Motivated by the discussions in:
https://github.com/modelcontextprotocol/registry/discussions/284
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
Locally and by running all of the tests
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
Yes, it changes both the API and the format of the seed file
## 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
---
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
Co-authored-by: adam jones <domdomegg+git@gmail.com>
|
||
| .. | ||
| examples.md | ||
| README.md | ||
| registry-schema.json | ||
| repository_references.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
- registry-schema.json - A more constrained version of
schema.jsonthat the official registry supports
Validation Tools
Two validation tools are provided in the repository's tools/ directory:
- validate-schemas - Validates that
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