capabilities
Capabilities are the feature sets a client and server declare during initialize. Each side announces what it supports, such as tools, resources, prompts, or logging, and neither is expected to use anything the other did not declare. It is a negotiation, not a fixed list every implementation has to satisfy.
What are MCP capabilities?
Capabilities are the declared feature sets exchanged during initialize. The server says what it offers; the client says what it can consume. Each side reads the other's declaration and adjusts.
This is how the protocol supports partial implementations without every client needing to handle every feature.
What can a server declare?
The common ones are tools, resources, and prompts. A server can also declare support for subscriptions and for change notifications, signalling that it will tell the client when its lists change instead of expecting a poll.
Tools are the capability nearly everyone implements and the one worth checking first: a server declaring tools is a server you can call tools/list against.
Why does the declaration matter if you can just try the call?
Because a well-behaved client should not call what was never offered, and a server is entitled to reject a method it did not declare. Trying anyway turns a clean negotiation into error handling.
It also matters for reading a connection record honestly. A server that declares only resources and no tools is working correctly when tools/list returns nothing, and describing that as a failure would be wrong.
Example
Every one of the 14 servers we reached on 5 August 2026 declared tool support and answered tools/list, returning 288 tools between them. A server declaring only prompts would have completed the same initialize exchange perfectly well and then had nothing to say to a tool-oriented client, which is a difference in capability rather than a difference in quality.