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.
Quick reference
TL;DR
Check the server's capabilities during initialize and degrade gracefully up front; never blindly call a feature the server never advertised.
Imagine plugging a new appliance into a wall socket. Before you switch it on, you check whether the socket actually supplies what the appliance needs. If the socket has no grounding pin, you do not just flip the switch and hope. You either pick a different socket or tell the user the appliance will run in a limited mode. MCP capability negotiation works the same way. During the opening handshake, the server hands the client a list of what it actually supports. The client reads that list first. If a feature is missing, the client disables the matching button or warns the user, instead of firing a call that is doomed to error.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A single closed deployment where client and server ship together and versions are locked If both sides are built and released as one unit, the capability set is known at build time, so dynamic detection adds little.
A feature is mandatory for the app to function at all If the missing capability makes the app pointless, degrading is meaningless; you should fail fast with a clear setup error instead.
Prototyping against one fixed server you fully control When you own both ends and never swap servers, hard-coding the known capability set is faster than building negotiation handling.
Quick scan · 2–4 min
Everything important, quickly.
4 min: the initialize handshake + what each side advertises + why detect at init not runtime + graceful degradation patterns + compatibility payoff.
Side-by-side
Behavior
When detected
User experience
Graceful degradation
At initialize, from capabilities object
Feature hidden or explained; no failed call
Call anyway, handle error
At runtime, via error response
Wasted round trip; cryptic error to debug
Silent skip
At runtime, no signal
Functionality vanishes with no explanation
Assume full support
Never; assumption only
Breaks against any partial server
Real-world examples
Real products, models, and research that use this idea.
1Claude Code and Claude Desktop read each MCP server's capabilities at session start and only register the tools and resources the server advertised.
2Cursor and Zed negotiate capabilities per MCP server, so a filesystem server without subscriptions simply omits live update behavior in their UIs.
3The official mcp-inspector tool surfaces the negotiated capabilities object, letting developers confirm what a server declared before any call is attempted.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat exactly does the client advertise back to the server during capability negotiation?
Sign in or go Pro to see the approach for this follow-up.
QHow does capability negotiation give MCP forward and backward compatibility?
Sign in or go Pro to see the approach for this follow-up.
QWhat should a client do if a server sends a list-changed notification after init?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Calling a capability the server never advertised and treating the runtime error as the discovery mechanism. The handshake exists precisely to avoid that.