MCP Capabilities Explained

Status in the 2026-07-28 spec: core

MCP capabilities are short declarations of which optional features a client or server supports. A server says "I offer tools and resources." A client says "I can ask the user questions." Each side may then use only what the other has declared.

In the 2026-07-28 spec, clients declare capabilities on every request, and servers advertise theirs through server/discover. Before that, both sides swapped capabilities once, in an initialize handshake.

This page lists every capability in the current spec, as of October 2026, using the architecture page and the official schema.

What capabilities are

The architecture page describes "a capability-based negotiation system where clients and servers declare their supported features on each request." It adds a rule both sides must follow: "Both parties must respect declared capabilities throughout the interaction."

Capabilities are mostly empty objects. An empty {} means "supported, no extra settings." Some have flags, such as listChanged: true, meaning the server can notify you when its list changes.

Why they exist

MCP is built so "features can be added to servers and clients progressively." A tiny server might offer two tools and nothing else. A full desktop app might support every client feature. Capabilities let these very different programs work together without guessing.

They also protect users. A server "MUST NOT rely on capabilities the client has not declared," per the base protocol page. So a server cannot ask a user a question through a client that never said it could show one.

The capabilities in 2026-07-28

Server capabilities

Client capabilities

The deprecation dates come from the deprecated features registry. Deprecated capabilities still work, but new implementations should not adopt them.

How capabilities are declared

Clients: on every request

Clients put capabilities in _meta under io.modelcontextprotocol/clientCapabilities. The base protocol page marks that field as required on every request. A request without it is malformed, and the server must reject it with -32602 (Invalid params).

The value should be the "client capabilities relevant to this request." So a client can send {} on a simple tool call, and include elicitation when it is ready to answer questions.

Servers: through discovery

Servers list their capabilities in the server/discover response, under capabilities. The architecture page notes that "implemented server features must be advertised in the server's capabilities," and that tool calls require "the server to declare tool capabilities."

When a capability is missing

If a server needs a client capability that was not declared, it returns a MissingRequiredClientCapabilityError. Here is the schema's example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32021,
    "message": "Server requires the elicitation capability for this request",
    "data": {
      "requiredCapabilities": { "elicitation": {} }
    }
  }
}

On HTTP, that response must also use status 400 Bad Request. The client can then decide whether to retry with the capability declared.

The multi round-trip requests page applies the same rule. If a client does not declare elicitation, the server "MUST NOT include any elicitation/create requests" when it asks for input. See MCP multi-round-trip requests.

Extensions as capabilities

Optional extensions, such as MCP Apps or Tasks, are declared inside capabilities.extensions, keyed by an identifier like io.modelcontextprotocol/tasks. The versioning page says that if only one side supports an extension, the supporting side "MUST either revert to core protocol behavior or reject the request with an appropriate error." Our page on how MCP extensions work goes deeper.

What changed across spec versions

• 2025-03-26 added the completions capability, per its changelog.
• 2025-11-25 exchanged capabilities once, inside initialize. Its lifecycle page shows a tasks capability for experimental tasks, plus roots, sampling and logging.
• 2026-07-28 moved client capabilities to per-request _meta and server capabilities to server/discover. It added the extensions field, moved Tasks to the io.modelcontextprotocol/tasks extension and deprecated roots, sampling and logging, according to the 2026-07-28 changelog.

Common mistakes

• Declaring capabilities once and assuming they stick. In 2026-07-28 nothing carries over between requests. Send them every time.
• Using undeclared features. A server that sends an elicitation to a client without elicitation breaks the spec.
• Advertising features you did not build. If you declare resources.subscribe, you must handle subscriptions.
• Adopting deprecated capabilities in new code. Skip roots, sampling and logging; use tool parameters, direct model APIs and stderr or OpenTelemetry instead.
• Looking for a top-level tasks capability. In 2026-07-28 Tasks is an extension, declared under extensions.

Next step

Capabilities are one piece of the bigger 2026 redesign. Read why MCP became stateless to see how per-request capabilities fit the new model, or browse the MCP specification hub.

Frequently asked questions