Skip to main content
server/discover lets a client query a server’s supported protocol versions, capabilities, and identity before sending any other requests. Servers MUST implement it.

Request

The request carries no body parameters beyond the standard _meta:

Response

The server replies with its supported protocol versions, capabilities, and identity. This operation supports caching.

When to Call

Calling server/discover is optional for clients — a client may invoke any RPC inline and handle UnsupportedProtocolVersionError if the server does not support the requested version. However, server/discover is useful in two scenarios:
  • Presenting server information. While a client doesn’t need to call server/discover to use the server, it’s a convenient way to retrieve the server’s identity, capabilities, and supported versions in a single request. For example, a client can present the capabilities a server supports from a single server/discover response instead of probing with separate tools/list, prompts/list, and resources/list requests.
  • stdio backward-compatibility probe. On stdio, there is no per-request HTTP status code to drive fallback. A client that supports both modern (per-request _meta) and legacy (initialize handshake) servers SHOULD send server/discover first; see stdio: Backward Compatibility for the fallback rules.
See Protocol Version Negotiation for the full version-selection flow. For HTTP-specific status codes returned for unknown methods, see the Protocol Version Header section in Transports.

Data Types

DiscoverResult

A discovery result includes:
  • supportedVersions: Protocol versions the server supports. The client should choose one of these for subsequent requests.
  • capabilities: Capabilities the server supports (tools, resources, prompts, etc.)
  • serverInfo: Name and version of the server software
  • instructions: Optional natural-language guidance for LLMs on how to use this server effectively