What is Capability Discovery?
Also called Capability Negotiation, Feature Discovery.
Capability discovery is the exchange at the start of a connection in which each side declares what optional features it supports, so both can agree on a working subset. It lets a protocol evolve without breaking older peers, because a participant simply does not use a feature the other side did not advertise. The Model Context Protocol performs this during initialization.
Without negotiation, a client must either assume every server implements every feature or guess by trying and handling failures. Both are fragile. Declaring capabilities upfront turns an unpredictable runtime error into a known fact before any real work begins, so the client can hide unavailable functionality rather than presenting an option that will fail.
The exchange usually happens once as part of a handshake. Each side sends a structure listing the optional features it supports, sometimes with sub-options such as whether it will emit change notifications for a given collection. The agreed set governs the session, and a peer that receives a request for something it never advertised may reject it outright.
This is distinct from listing the actual contents of a connection. Capability discovery answers whether a category of functionality exists at all; separate listing operations then enumerate the specific items within it. A server may advertise that it offers tools, after which the client asks which tools those are and receives their names and input schemas.
Discovery is also a version negotiation mechanism. Because unknown fields are ignored and unadvertised features go unused, a newer implementation can talk to an older one at the intersection of what both understand, which avoids a hard version wall every time the protocol adds something.
Key points
- Each side declares supported optional features at connect time
- Turns runtime failures into upfront known limits
- Separate from listing the concrete items available
- Enables newer and older peers to interoperate
- Requests for unadvertised features may be refused
In practice
On connecting, a client announces that it can handle elicitation prompts, and the server announces that it provides tools and resources but not prompt templates, and that it will send notifications when its tool list changes. The client therefore renders no prompt template menu at all, subscribes to tool change notifications, and only then asks the server to list its available tools.