A client was upgraded to support elicitation, while a server it uses was built earlier and offers only tools. The two cannot be upgraded together. How does MCP let them keep working?
Select an answer to reveal the explanation.
Short Explanation
Capabilities are like each side saying what it brought to the potluck: you use what's on the table and skip what isn't. The client can offer elicitation, the server just never asks for it. Nobody has to upgrade in lockstep.
Full Explanation
Capability declarations let MCP implementations adopt features progressively. The client states io.modelcontextprotocol/clientCapabilities on every request, and the server advertises its own capabilities through server/discover. Each side uses only features the other has declared: a server MUST NOT rely on capabilities the client did not declare, and a client should not attempt operations the server does not support. Here the client offers elicitation and the server simply never requests input, while tool listing and calling work exactly as before. This lets each side evolve on its own schedule. Requiring identical feature sets would defeat the purpose of capabilities, which exist precisely so that partially overlapping implementations interoperate. Having the server emulate client features is backwards; client features are things the client offers to the server, and a server cannot create them by itself. Forcing the client to downgrade its revision and permanently drop elicitation confuses protocol versions with optional features; both sides can speak the same revision while supporting different optional features. Exam caveat: if a server does need a client capability that was not declared, it returns MissingRequiredClientCapability, error -32021, listing what is missing. Operational check: compare the client's declared capabilities with the server's discovery result and confirm only overlapping features are exercised.