hmm i am not sure that's needed . I think can totally just call it the Registry Card, which is based on the MCP Server Card, or just plain keep server.json. I think you are right in that Extended MCP Server Card is quite awkward.

Moving it back to just server.json for now: cb9da9b

Will think more on it but I think that's a reasonable default path forward here.

I have some questions:

1. Is supportedProtocolVersions not mandatory to be defined here in server.json (and as a consequence in server card)?
2. Would it be clearer to define a regex pattern for the string array items?

There have been other discussions in the community about removing the release date from the server.json and mcp protocol $schema url and replace it with major version indicators. This would have as consequence the fact that supportedProtocolVersions array items could be only something like v1, v2 etc.

With a regex pattern to mention if it's a date format or a vX format it will be clearer for consumers in which direction this will go.

Does anyone know if this is a good card

Is supportedProtocolVersions not mandatory to be defined here in server.json (and as a consequence in server card)?

Correct, optional in both cases.

Would it be clearer to define a regex pattern for the string array items?

Probably reasonable to include a regex that enforces this, yes. I think we can get to that kind of detail when we properly enumerate the schema in this SEP (e.g. instead of delegating out to the Registry server.json docs) after we align on the remaining open conceptual questions.

There have been other discussions in the community about removing the release date from the server.json and mcp protocol $schema url and replace it with major version indicators.

This is accomplished by the major version (v1) in the $schema: https://static.modelcontextprotocol.io/schemas/v1/server.schema.json

I get the $schema-based versioning, but it would probably be still better to keep supportedProtocolVersions non-optional. It makes protocol compatibility explicit and gives us a clean path to multi-version support later, rather than relying on inference.

I'm on the fence on making supportedProtocolVersions required --

On one hand:

• Every remotes/packages of course has a set of supported protocol versions, whether or not it is explicitly documented
• So it seems reasonable to require it be documented
• This would imply a design principle like "if the value exists implicitly, it should be required in the shape"

On the other hand:

• We are likely to make additive changes to this shape over time
• Doing so might put us in a position where a value that exists implicitly gets added as optional to the spec for the purpose of backwards compatibility
• And so adopting a principle of "if the value exists implicitly, it should be required in the shape" feels inevitably short-lived

So I'm inclined to advocate for a principle more like, "Server Cards will deliberately have a minimum amount of required fields, and server maintainers are encouraged to document their servers as comprehensively as made available by the shape so as to maximize compatibility and discoverability with other systems". That I think we can keep consistent over time.

I'm partially biased here knowing that making supportedProtocolVersions required here would be a breaking change to server.json - so if there another more compelling way of thinking about this I'm keen to hear it.

I thought again about this and I agree with you @tadasant that supportedProtocolVersions should be optional in server.json but server maintainers are still encouraged to document it.

I am thinking about the server card and well-known discovery mechanism as well, and I tend to advocate for the fact that supportedProtocolVersions in server-card does not bring additional value for the client at all in it's discovery phase.

Even if this info of supportedProtocolVersions is there in the server-card, the client would still need to negotiate the protocol version in the mcp initialization lifecycle phase, because this is how the protocol is designed. The client cannot say "we just skip initialization phase because I found in the supportedProtocolVersions a matching value...".