Preview deployment for your docs. Learn more about Mintlify Previews.

💡 Tip: Enable Workflows to automatically generate PRs for you.

Preview deployment for your docs. Learn more about Mintlify Previews.

💡 Tip: Enable Workflows to automatically generate PRs for you.

Cross-posting from Discord my concern for visibility. I worry that MAY doesn't give MCP server implementers much incentive to actually report their server info.

To recap the parallel drawn in the Discord thread: this field is effectively a user-agent equivalent, and the HTTP RFC uses considerably stronger language for User-Agent (SHOULD), meaning the User-Agent should be sent by default unless explicitly configured otherwise. I think this model could work as well, even though the preferred choice would be to make the serverInfo mandatory as is the clientInfo in the current draft spec. This would allow enforcing visibility much easier on the network side.

@olaservo, @ostefano I would be curious to hear your thoughts on this since you participated on the Discord thread.

Also worth noticing that this PR actually reduces visibility by making clientInfo optional as well, while it was previously required.

There are 3 open decisions on this:

1. MAY vs SHOULD vs MUST

In a recent CM meeting we discussed making this info available on every request but optional (similar to how user agents are handled in HTTP today). For context:
prior spec versions required both clientInfo and serverInfo once, at initialize, and the current draft requires clientInfo on every request.

• MAY — purely informational; implementations opt in
• SHOULD — recommended default; well-behaved implementations send it, omitting is still conformant
• MUST — every message carries it; guaranteed identity on every reply (for better or worse)

For comparison, RFC 7231 says:

A user agent SHOULD send a User-Agent header field in each request unless specifically configured not to do so.

From the SDK perspective it looks like it's currently required in most if not all -- so users more or less have to specify it today.

2. Schema requiredness of _meta.io.modelcontextprotocol/serverInfo

JSON Schema required is hard validation, so this is coupled to (1):

• Optional — the only coherent choice for MAY or SHOULD, but a deviation from prior spec versions, where the field was required
• Required — only coherent with MUST; also means all schema examples need serverInfo and validators reject responses without it

3. server/discover duplication

• Duplicate content — serverInfo appears twice (required in the body, optionally in _meta); closest to the shape SEP-2575 merged, at the cost of redundancy
• Move to _meta-only — drop the body field and add a DiscoverResultMeta that requires serverInfo in _meta (the SubscriptionsListenResultMeta pattern); one canonical location, no duplication

The discussion w/ @pja-ant and @nickcoai this morning our preference is the following:

1. The language should be "SHOULD" -- we can't actually force clients/servers to populate these fields, and this is aligned with the how user-agents work in HTTP today. Most SDKs have this as required input today, so there's still encouragement for it to be included.
2. Optional in the schema -- if the language is "SHOULD", the schema should reflect that.
3. Remove duplication -- having the field in two places introduces concerns with it drifting. We will just return it in _meta.

The discussion w/ @pja-ant and @nickcoai this morning our preference is the following:

1. The language should be "SHOULD" -- we can't actually force clients/servers to populate these fields, and this is aligned with the how user-agents work in HTTP today. Most SDKs have this as required input today, so there's still encouragement for it to be included.
2. Optional in the schema -- if the language is "SHOULD", the schema should reflect that.
3. Remove duplication -- having the field in two places introduces concerns with it drifting. We will just return it in _meta.

I agree with this outcome.
Thank you for taking the time to address this!

I am a little dubious, some people do put garbage in initialize, but GitHub get's tremendous value out of the client field, to the extent we literally implemented persistent sessions in Redis with zero SDK support explicitly to persist the initialize payload across associated requests.

There are other things we can correlate (like the App identity of the client from auth perspective), but the app is often not the actual name of the client.

Having read all the above I still don't know that making client info optional is directionally right. I understand the arguments, it's just a user provided string, it's not a strong or reliable identity, should never be used for auth etc. but if this change would lead to clients not providing the values, that would be damaging to the protocol from my perspective.

I guess I am personally only happy to give up sessions with the guarantee that the the data that was required to create a session is provided statelessly.

This sounds like a walkback on that, now I might lose something I actual find useful. 😅

Most SDKs have this as required input today, so there's still encouragement for it to be included.

If this goes ahead, I really hope this remains accurate and in practice it's only a technical change and the reality is that everyone continues to provide this (which I will concede is the case with user agents, with should language).

Because this ended up being a change to the schema, it went up for a vote to the Core Maintainers today. It passed with 7/7 voters approving.

I appreciate moving to SHOULD for the client info.

@kurtisvg thank you and the core team for your patience while discussing this change over the course of the past few weeks, and for driving this to a conclusion 👍