The client sends an initialize request with its protocol version and a capabilities object listing features it supports. The server responds with its own protocol version and capabilities object. The client then sends notifications/initialized to confirm. From that point, each side only calls features the other advertised. This mutual opt-in lets MCP evolve without breaking older peers.
**Capability negotiation** is the feature exchange that happens at the very start of every MCP session, inside the `initialize` handshake.
The flow has three messages. First, the client sends an `initialize` request containing its protocol version, client info (name and version), and a `capabilities` object listing the optional features it supports. Second, the server responds with the agreed protocol version, its own server info, and its own `capabilities` object. Third, the client sends a `notifications/initialized` notification to signal it has read the response and the session is open.
The server's capabilities might include keys like `tools`, `resources`, `prompts`, `logging`, and `completions`. The client's capabilities might include `roots`, `sampling`, and `elicitation`. Each key is opt-in: if a server does not implement resources, it omits that key entirely.
Once the exchange finishes, both sides know the intersection of supported features. The client will not call `resources/list` against a server that did not advertise resources. The server will not issue a `sampling/createMessage` request to a client that did not advertise sampling. This mutual agreement is what makes MCP forward compatible: new features are invisible to peers that never advertised them, so nothing breaks.
**Capability negotiation** is the feature detection step inside MCP's `initialize` handshake. Both sides declare what they support, and from that point on each side calls only features the other advertised.
The sequence is three messages. The client sends `initialize` with its protocol version (a date string like `"2026-03-26"`), client info, and a `capabilities` object. The server replies with the agreed protocol version, server info, and its own capabilities. The client then fires a `notifications/initialized` notification, and the session is open.
Server capabilities in the 2026 spec commonly include `tools` (callable functions, with an optional `listChanged` sub-flag), `resources` (readable data identified by URI, with optional `subscribe` and `listChanged`), `prompts` (user-invoked templates), `logging` (structured log emissions), and `completions` (argument autocompletion). Client capabilities commonly include `roots` (workspace directory hints), `sampling` (the client can run LLM completions on the server's behalf), and `elicitation` (the client can prompt the user for input mid-call).
This matters because MCP is a living spec. Features ship every few months. Without negotiation, every addition would break older peers. With negotiation, a 2026 server talking to a 2024 client degrades gracefully to the shared feature set. The intersection of advertised capabilities is always a valid working subset.
The practical debugging note: when a feature is not working, the first check is always the initialize trace. If either side did not advertise the capability, no downstream fix will help.
Quick reference
TL;DR
During initialize, client and server each declare supported features via a capabilities object; both sides then stick to the intersection, enabling forward compatibility.
Imagine two kids meeting at a playground for the first time. Before they start playing, each one says which games they know: 'I know tag, hide and seek, and kickball.' The other says 'I know tag and freeze dance.' They agree to play tag because both listed it. Neither suggests a game the other never learned.
MCP works the same way. When a client and server first connect, each sends a short list of features it supports. From then on, both stick to only the features they share. If the server later learns a new trick, older clients that never listed it simply ignore it. Nobody breaks. Nobody gets confused.
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.
Building a closed system where you control both client and server and pin a single MCP spec version. Capability negotiation is still required for spec compliance, but you can hard-code the expected feature set because both sides ship together.
Trying to enforce authorization or rate limits via the capabilities object. Capabilities are feature flags, not access controls. Authentication belongs at the transport layer; rate limits belong in the server's call handlers.
Skipping the notifications/initialized notification after receiving the server response. The spec requires it. Some servers wait for the notification before accepting other calls; omitting it leaves them in a half-open state.
Quick scan · 2–4 min
Everything important, quickly.
4 min: walk the three-message initialize sequence, list common server and client capabilities with sub-flags, explain forward compatibility via mutual opt-in, and close with the debugging heuristic of checking the initialize trace first.
Real-world examples
Real products, models, and research that use this idea.
1Claude Desktop announces `roots` and `sampling` client capabilities; servers configured in the desktop config can rely on Claude to surface roots and accept sampling requests.
2A simple search MCP server advertises only `tools`; the client never attempts `resources/list` against it because the resources capability is absent.
3When a new spec revision adds a capability (e.g., a hypothetical `samplingV2`), older clients that never advertise it keep working because the server sees no flag and never calls it.
4MCP Inspector prominently displays the initialize exchange so developers can verify which capabilities each side advertised before debugging downstream calls.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat should a client do if it attempts to call a feature the server did not advertise?
Sign in or go Pro to see the approach for this follow-up.
QHow does capability negotiation interact with protocol version?
Sign in or go Pro to see the approach for this follow-up.
QWhat happens when a server's tool list changes mid-session?
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
Assuming every MCP server supports every feature. Servers advertise only what they implement, and the client must check before calling anything beyond initialize.