In MCP 2026-07-28, what does a client give up by never calling server/discover?

## The asymmetry, and why it is safe MCP revision 2026-07-28 says servers MUST implement `server/discover` and clients MAY call it. That reads oddly until you connect it to the statelessness rule the same revision introduced. Every request is self-contained and carries its own protocol version and capabilities in `params._meta`; servers MUST NOT rely on prior requests over the same connection to establish context; an open connection, such as a stdio process, is not a conversation or a session. Nothing about a `tools/call` is invalid because no discovery preceded it. The server evaluates the request on what the request itself carries. Contrast the removed era: up to 2025-11-25 the first message HAD to be `initialize`, and everything after it depended on that exchange. Skipping it was a protocol error. In 2026-07-28 skipping discovery is a design choice. ## What is actually forfeited **The supported-version list.** Without `supportedVersions`, a client sends the revision it prefers and finds out from the response whether the server accepts it. The failure is visible and recoverable — the server rejects the request and reports what it does support — but it costs a round-trip in the failing case and puts the retry logic on the hot path instead of at configure-time. **The capability preview.** `capabilities` tells a client which feature areas a server offers before it asks. Skipping it means probing: call `prompts/list` and see whether the method exists. Functional, noisier. **The instructions.** `instructions` is optional prose the server author wrote about how to use the server. It appears nowhere else — tool and prompt descriptions travel with their own list results — so a client that never discovers can never show it or give it to the model. **serverInfo.** The self-reported name and version in `_meta` are the natural thing to render in a server list. Results generally SHOULD carry serverInfo in `_meta`, so a client may pick it up from another call, but discovery is where a host expects to read it first. **The cache contract.** `ttlMs` and `cacheScope` are the server's statement about how long and how widely its profile may be reused. Without them a client has no sanctioned caching story for the server's shape. ## What is NOT forfeited No capability is gated on discovery. There is nothing a server unlocks because you discovered it, because unlocking would be exactly the connection-scoped state the revision removed. Cross-call state, where a workflow needs it, lives in server-minted handles passed as ordinary tool arguments — never in a prior handshake or discovery call. ## The judgment call Skipping is defensible when the client is purpose-built: a CI job or a script that ships against one known server, knows its version, and calls two tools. Every request already declares the version, so the deployment is pinned by construction and discovery would just be a startup round-trip. Skipping is a poor default for a general host — a desktop app, an IDE, an agent platform — that must present arbitrary user-added servers. Such a host wants the name, version and instructions to render, the capability list to decide which UI affordances to show, the version list to detect an incompatible server at configure-time rather than mid-task, and the cache hints to keep all of that cheap. The cost is one round-trip when a server is added, amortised over the whole `ttlMs` window. ## What a strong answer sounds like "Nothing breaks, because every request is self-contained under 2026-07-28. You lose the up-front profile — supported versions, capabilities, instructions, serverInfo and the cache hints — so mismatches surface as rejected requests instead of at configure-time. For a pinned single-server script that is fine; for a host that shows many servers to a user it is a bad trade, and I'd discover once and cache to the server's ttlMs and cacheScope."