What is the correct client behavior when a server's capabilities object omits a feature the client needs?

When an MCP client connects to a server, the first thing they do is shake hands. The client sends an `initialize` request, and the server replies with a **capabilities** object listing what it actually supports: tools, resources, prompts, and finer-grained flags like resource subscriptions. The whole point of that exchange is so the client knows up front what is available. So the correct behavior, when a feature you wanted is missing, is to notice it right then and adapt. You either disable the matching button in the UI or tell the user the feature is not available here. Calling the missing feature anyway and waiting for an error is wrong. It wastes a round trip and gives the user a confusing failure. Silently skipping it is also wrong, because the user loses functionality without knowing why. The right answer is graceful degradation: detect the gap during initialization, then either inform the user or hide the feature before any call is made.

The correct behavior is graceful degradation detected at initialization, not at call time. During the **capability negotiation** step of the MCP handshake, the client sends `initialize` and the server responds with a capabilities object. That object declares which primitives the server offers: tools, resources, prompts, and sub-flags such as resource subscriptions or list-changed notifications. The client is expected to read this object and only use features the server actually advertised. So if a needed capability is absent, the client should detect that gap immediately. It then adapts the experience. It disables the relevant UI control, or it tells the user that feature is unavailable on this server. Both choices keep the user informed. The other options are anti-patterns. Calling the feature anyway turns a known-impossible operation into a runtime error and a wasted round trip. Silently skipping it strips functionality without explanation, so users cannot tell broken from unsupported. And servers are explicitly not required to implement every capability, so assuming full support is simply false. The handshake exists precisely so each side only uses what the other declared.