server.json should be immutable

At the moment I think server.json is a bit of a pain because it conflates two things:

information about the server itself
information that the registry uses to manage the server, e.g. tags like is_latest, published_at or the registry-generated id

I 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

I agree that server.json should be immutable per version per MCP server entry. The intent is for server.json (here) to be that universal, static artifact, and for the /servers/:id endpoint (as defined here) to serve as that "registry management" information (a large subset of which is aligned with server.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/:id and /servers should return a shape that looks more like:

{
  "id": "75d362b1-0490-46e9-a3c1-f4ad2d5cb7c9",
  "serverJson": { /* the immutable server json */ },
  "registryMeta": {
    "is_latest": true,
    "published_at": ...
  }
}

I'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 serverJson as this is what is being published by vendors or that's not correct?

@tadasant

@tadasant Yeah that's fair! I guess I'd be happier with putting all the extra stuff under a x-official-registry property 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 like x-anthropic.com/security-scanned-at or x-anthropic.com/featured-on-connectors-homepage)

To join up this and a couple other issues, I opened a discussion here with a concrete proposal for that tackles this and others: #284

Resolved in #298

Navigation Menu

Repository navigation

server.json should be immutable #263

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

server.json should be immutable #263

Description

Activity

tadasant commented on Aug 13, 2025

domdomegg commented on Aug 14, 2025

tadasant commented on Aug 18, 2025

rdimitrov commented on Aug 18, 2025

domdomegg commented on Aug 18, 2025

domdomegg commented on Aug 19, 2025

domdomegg commented on Aug 23, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions