Capability Discovery

If a client assumed every server it connects to supports the same fixed set of features, it would break the moment it talked to a server built differently, or miss out on capabilities a richer server actually provides. Capability discovery avoids that by having the client explicitly ask, and the server explicitly answer, before any real work happens.

In protocols like MCP, this happens right after a connection opens: the client and server negotiate what each side supports, and the server returns a description of its available tools, resources, and prompts. The client then only offers the model the capabilities the server actually confirmed it has.

This pattern isn't unique to MCP — it shows up anywhere a client needs to adapt to a variable set of server capabilities rather than assuming a fixed one, including systems where different servers of the same protocol expose very different sets of tools.

How it works

When a connection is established, the client sends a request asking what the server supports. The server responds with a structured description — for an MCP server, this typically means a list of its tools (with their manifests), the resources it can serve, and any prompt templates, discovered at connection time rather than assumed in advance. The client stores this and uses it to decide what to present to the model as available options; if the server is later reconnected to or its capabilities change, the discovery step can be repeated so the client stays in sync.

Common misconceptions

FAQ