Background

This is related to but distinct from the tool grouping discussions (#1567, #1772). Those proposals address how servers organise and expose tools; this proposal addresses how servers know which tools are appropriate for the calling model in the first place.
It's also worth noting that the Apify mcp-client-capabilities project explicitly acknowledges that the current initialize capability negotiation is insufficient for communicating client details, and built an out-of-band lookup table as a workaround. That workaround is a signal this gap is already felt in the community.

The problem

MCP servers have no way to know the capability level of the model making requests. This matters in practice: a server exposing 20 tools works well for a capable frontier model but causes weaker or smaller models (locally-served Ollama models, smaller distilled models) to miss tools, default to familiar ones, or fail to chain tools correctly across a turn.
The current workaround is out-of-band configuration — operators mint different API keys for different model tiers and filter the tool list server-side. This is a per-server hack rather than a protocol-level solution, and it requires the operator to know at configuration time which model tier a deployment is for. There is no runtime signal.

The proposal

Extend clientInfo in the initialize handshake with an optional modelTier field (or similar), allowing the client or operator to declare the capability level of the model making requests:

json{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "sampling": {}
    },
    "clientInfo": {
      "name": "my-agent",
      "version": "1.0.0",
      "modelTier": "lite"
    }
  }
}

Servers that understand modelTier can adapt their tool surface or response behaviour accordingly. Servers that don't recognise it ignore it. Fully backwards compatible.

Design considerations

Set by the operator or client application, not the model itself. A model declaring its own tier has an obvious incentive problem — a weak model over-declaring gets more tools than it can handle. This should be set by whoever configures the client, the same party who decides which model to use.
Advisory and optional. Servers that don't use it ignore it. No breaking change.
Fits naturally in clientInfo. The handshake already carries name and version in clientInfo. This extends an existing pattern rather than introducing a new one.
Enables server-side optimisations currently impossible without out-of-band coordination: tool surface filtering, response verbosity tuning, format adaptation.

Open questions

• Should this be a structured enum (lite / standard / full) or free-form like HTTP User-Agent? An enum is more actionable for servers; free-form is more flexible as the model landscape evolves.
• Should it live in clientInfo or as a new top-level capabilities entry? clientInfo feels right since it describes the client, not a protocol feature.
• Are there security implications to servers trusting this declaration? Since it's advisory and set by the operator (not the model), trust is similar to User-Agent — useful for optimisation, not for access control.
• Should this be standardised as a well-known field in the spec, or left as a convention in clientInfo until there's more community signal?

Relation to tool grouping proposals

#1567 and #1772 propose that servers declare groups of tools with semantic meaning. This proposal is complementary: client capability declaration tells the server which group is appropriate for this client, without requiring separate per-deployment configuration.