MCP-DSC-002
DiscoverResult advertises supported protocol versions
“`supportedVersions`: Protocol versions the server supports. The client should choose one of these for subsequent requests.” — spec anchor
How to fix this
Return a `supportedVersions` array in the DiscoverResult naming every protocol revision the server accepts. The client selects one from that list for its subsequent requests.
Example: failing and passing
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"resultType": "complete",
"capabilities": {"tools": {}},
"ttlMs": 3600000,
"cacheScope": "public"
}
}{
"jsonrpc": "2.0",
"id": 1,
"result": {
"resultType": "complete",
"supportedVersions": ["2026-07-28"],
"capabilities": {"tools": {}},
"ttlMs": 3600000,
"cacheScope": "public"
}
}How the validator checks this
Probe P1.1, against a streamable-http server on the modern protocol. What it reports:
- pass
- DiscoverResult advertises supportedVersions
- fail
- DiscoverResult has no supportedVersions field — it is required, and is how a client chooses the version for subsequent requests
Quoted from the probe that runs this check, so it cannot drift from what the validator actually reports.
This rule is checked deterministically: a fail here is a certain violation, not an inference.
Checked in the same request as MCP-DSC-001, MCP-DSC-003, MCP-DSC-004, MCP-DSC-005, MCP-STL-003, MCP-RES-001, MCP-RES-002, MCP-RES-005.
Check your own server against MCP-DSC-002
Probe P1.1 checks MCP-DSC-002 in the same request as 8 other rules, so one run shows your server's result for this rule next to the rest. Validate a server or read how the validator works.
Background on this topic: server/discover explained.
Other Discovery and capabilities rules
- MCP-DSC-001server/discover is implemented
- MCP-DSC-003Advertised versions include a currently-supported revision
- MCP-DSC-004Extension identifiers use a valid non-reserved reverse-DNS prefix
- MCP-DSC-005Results carry io.modelcontextprotocol/serverInfo in _meta