Implement the server/discover RPC on an MCP server so clients can select a protocol version and read capabilities in one call

Documented steps

1. Read https://modelcontextprotocol.io/specification/2026-07-28/server/discover — server/discover is new in the 2026-07-28 revision and servers MUST implement it.
2. Accept a JSON-RPC request with method 'server/discover'. It carries no body params beyond the standard params._meta object.
3. Read params._meta['io.modelcontextprotocol/protocolVersion'] (required) and params._meta['io.modelcontextprotocol/clientCapabilities'] (required); params._meta['io.modelcontextprotocol/clientInfo'] is optional.
4. Return a DiscoverResult with resultType 'complete'.
5. Set supportedVersions to the array of protocol version strings your server accepts, e.g. ['2026-07-28','2025-11-25']. The client picks one for subsequent requests.
6. Set capabilities to the server capability object (tools, resources, prompts, and an 'extensions' map for any opted-in extensions such as 'io.modelcontextprotocol/tasks').
7. Add _meta['io.modelcontextprotocol/serverInfo'] = {name, version} (spec: SHOULD).
8. Optionally set instructions: a natural-language string guiding an LLM on how to use the server effectively.
9. Include caching hints: ttlMs (integer milliseconds, MUST be >= 0) and cacheScope ('public' or 'private'). server/discover output is normally 'public' with a long ttl, e.g. 3600000.
10. On Streamable HTTP, still enforce the transport headers: MCP-Protocol-Version must be present and must equal the body _meta protocol version, and Mcp-Method must be 'server/discover'.
11. If the requested version is unsupported, return UnsupportedProtocolVersionError (-32022) with data.supported listing your versions and data.requested echoing theirs, HTTP 400.
12. Verify: POST server/discover with a bogus version and confirm you get -32022 with a usable data.supported array; then POST with a supported version and confirm supportedVersions, capabilities and ttlMs/cacheScope are all present.