Authors: Michael Bleigh (@mbleigh)
Status: draft
Type: Standards Track
Created: 2025-08-22

Abstract

The SEP proposes that during the initialize call, clients and servers may declare not only the capabilities they support but also the converse, allowing clients to declare the server capabilities they utilize and servers to declare the client capabilities they utilize.

Motivation

MCP Clients have varied and inconsistent support for core primitives. While most clients support tools, few support prompts or resources. This "lowest common denominator" effect discourages MCP Server developers from leveraging prompts and resources even when they are appropriate because maximal client support requires minimal use of uncommon primitives.

Servers can be adaptive -- if I normally use resources for a feature of my server but a client doesn't support them I can expose a get_resource tool instead that accomplishes the same purpose. However, I can only do this if I know the client doesn't support resources.

Capability negotiation today provides declarations of which features a client/server offers, but not which ones it utilizes. This makes it difficult for servers to gracefully degrade their feature set to match the utilized capabilities from the client. Some examples:

1. A server might provide load_prompt or read_resource tools if prompts or resources aren't available.
2. A server might turn on dynamic tool activation features if the client declares tools: {listChanged: true}.
3. A server might change the guidance it provides in a prompt based on whether the client supports resource notifications.
4. A server might write log messages to a local file if the client does not indicate it utilizes logs.

In all of these cases, knowing how the client will utilize the server allows the server author to dynamically adapt its behavior and logic to suit the client.

Without such a proposal, server authors will be forced to sniff client names to manually adjust behaviors similar to user agent sniffing in web browsers. The status quo encourages a more stagnant ecosystem that can't evolve and utilize new core capabilties quickly.

Specification

Utilized capabilities can be added in a backwards-compatible manner through an optional addition to the initialize specification:

  export interface InitializeRequest extends Request {
    method: "initialize";
    params: {
      protocolVersion: string;
      capabilities: ClientCapabilities;
+     utilizedCapabilities?: ServerCapabilities;
      clientInfo: Implementation;
    };
  }

  export interface InitializeResult extends Result {
    protocolVersion: string;
    capabilities: ServerCapabilities;
+   utilizedCapabilities?: ClientCapabilities;
    serverInfo: Implementation;
    instructions?: string;
  }

This allows bidirectional declaration of utilized capabilities from client to server and vice versa. While the motivation for this SEP is primarily targeted at server development concerns, providing it in both directions is more complete.

Rationale

An earlier discussion of this issue in #679 proposed two different approaches:

1. Combine client and server capabilities into a single object where utilized and provided capabiltiies are intermingled.
2. Rework capability negotiation to be based on provided and consumed RPC methods rather than the current "capabilities objects".

Proposal (1) would be workable but might be confusing to consume -- capabilities are generally specific to client or server at the moment, but in the future there may be overlapping capabiltiies.

Proposal (2) would require a substantial and potentially backwards-incompatible change without offering an outcome that outweighs the heavy implementation cost.

Backwards Compatibility

The proposal is fully backwards compatible as the new capabilities declarations are marked as optional. Depending on how adoption of the new negotiation goes, it might be beneficial to the MCP ecosystem to change it to required in a future version of the spec (to ensure consistent ability to gracefully degrade); however, a non-breaking change provides enough of a start for the present time.

Reference Implementation

None yet, but should be simple to add to any of the existing SDKs.

Security Implications

Declared utilized capabiltiies don't have a meaningful impact on security since it is optional and the existing negotiation protocol already reveals a client name to the server on initialization.