Repository navigation
server.json should be immutable #263
Description
Activity
I agree that
server.jsonshould be immutable perversionper MCP server entry. The intent is forserver.json(here) to be that universal, static artifact, and for the/servers/:idendpoint (as defined here) to serve as that "registry management" information (a large subset of which is aligned withserver.json)But I think this already the state of things? Maybe there is some implementation quirk leading to this not currently being the case. From a requirements perspective --
information that the registry uses to manage the server, e.g. tags like is_latest, published_at or the registry-generated id
These three fields are part of the /servers/:id response in the OpenAPI spec, but not part of the server.json spec; which I think is aligned with what you're proposing here. Are you seeing otherwise somewhere?
Ah okay - I guess maybe my proposal is:
/servers/:idand/serversshould return a shape that looks more like:{ "id": "75d362b1-0490-46e9-a3c1-f4ad2d5cb7c9", "serverJson": { /* the immutable server json */ }, "registryMeta": { "is_latest": true, "published_at": ... } }Reacted by Radoslav DimitrovI'm not opposed to that, but what do you think is the motivation for the change?
The registry-specific data seems like it could just be considered "MCP Registry vendor metadata" in line with this issue (though indeed whatever we conclude there might influence the precise final shape here). My gut would be to align with that as if the MCP Registry is just another "vendor" rather than introduce a one-off opinionated shape.
That means tools can upload a complete server.json
I think they still could even if we don't change anything; the uploaded artifact doesn't need to contain the registry-specific metadata.
I think the vendor metadata extensions are supposed to be part of
serverJsonas this is what is being published by vendors or that's not correct?@tadasant Yeah that's fair! I guess I'd be happier with putting all the extra stuff under a
x-official-registryproperty then (or whatever we do agree in #201) - rather than having it spread over the model as it is now. Will continue discussions there about what this looks like then move things over to that.@rdimitrov I think metadata could be added at two points:
- at publish time, a publisher might add extra vendor extension properties
- when registries host
server.json's they might want to add extra vendor extension properties (e.g. the Anthropic registry might want to add something likex-anthropic.com/security-scanned-atorx-anthropic.com/featured-on-connectors-homepage)
At the moment I think server.json is a bit of a pain because it conflates two things:
is_latest,published_ator the registry-generatedidI think we should split these up. That means tools can upload a complete server.json, without actually being some special weird subset of server.json without the registry values