Capability Negotiation

The first step in the negotiation is the exchange of supported MCP protocol versions. This ensures both client and server agree on a common set of JSON-RPC methods and message formats.

• The client initiates with an initialize request containing its protocol version.
• The server responds with its own version and supported features.
• If versions are incompatible, the connection is terminated to prevent undefined behavior.

The server declares the specific capabilities it provides, which fall into three core categories:

• Resources: Read-only data objects (files, database records) the server can serve, identified by URIs.
• Tools: Executable functions the client can invoke, each with a defined input schema.
• Prompts: Reusable template instructions for language models, containing variable placeholders.

This advertisement defines the entire interface the client can use for the session.

The client communicates which of the server's advertised capabilities it intends to use. This is not a selection menu but a declaration of the client's implementation support.

• The client lists which MCP features (e.g., resources, tools) its runtime can handle.
• This allows a server to optimize or even withhold certain capabilities if the client lacks support, preventing errors.
• It enables forward compatibility, where a server with newer features can still serve an older client using a common subset.

A critical technical outcome of negotiation is the synchronization of JSON Schemas for all tools. The server provides the complete input schema for each tool it advertises.

• The client caches these schemas locally.
• This allows the client to perform client-side validation of arguments before sending a tool invocation request.
• It also enables intelligent UI generation, where interfaces can be built dynamically from the schema definitions.

The negotiation concludes with the client sending an initialized notification to the server, signaling that the handshake is complete and the session is ready for normal operation.

• This two-step process (initialize request → initialized notification) mirrors the JSON-RPC protocol.
• After this point, the client can begin listing resources, invoking tools, and retrieving prompts.
• All subsequent communication uses the negotiated protocol version and operates within the declared capability boundaries.

The negotiation process includes defined error paths for incompatible or failed handshakes.

• If the server receives an initialize request for an unsupported protocol version, it must respond with a defined error and close the connection.
• If the client declares capabilities the server does not support, the server ignores the unsupported parts; the connection proceeds with the mutually understood subset.
• This robust error handling prevents silent failures and ensures sessions only begin with a clear, mutual understanding.