Host registry-schema.json alongside server.schema.json and define sync/versioning strategy
The following issue is about the 2 schemas describing the server.json format, their versioning and release strategy.
Currently:
- We have
server.schema.jsonhosted atstatic.modelcontextprotocol.iobut the version that is being served is old -
registry-schema.jsonis not hosted anywhere. It also refers to the older hosted version.
Next steps:
- Similarly to
server.schema.json,registry-schema.jsonshould be publicly hosted too - Additionally we have to define their release process, i.e. how often
registry-schema.jsonshould be synced with the latestserver.schema.jsonand how versioning will be handled.
btw just in case you hadn't seen it - the static file hosting is managed here: https://github.com/modelcontextprotocol/static. Happy to merge in PRs there as needed!
Maybe we can just make that the main place it lives and link to there (probably my preferred option), or can set up some pipeline to automatically sync them.
I did missed that 😄
I think it would be easier if the schemas continue to live in the registry repository to be honest. Contributing to another repo (static) and then going back here might become easily annoying/skipped. This is in case I understood your suggestion is to move the schemas to static and just reference them from here (registry).
In general I think it would be feasible to set up some automation so that whenever we do a registry release it opens a PR against mcp/static with the released schemas and proper versioning. Would that make sense? I also wanted to experiment auto-generating the server.json schema off of the Go structs. If successful that would fit nicely too since the structs already live in this repo.
Yep that sounds reasonable!
Also flagging I think there was some discussion in https://github.com/modelcontextprotocol/registry/issues/139#issuecomment-3206989653 about whether server.json should live in registry or elsewhere. I think reasonable to keep in registry for now, but might migrate somewhere else in future (possibly actually lives in static for example) so I might not prioritize the automation very highly if it's a big pain!