Skip to content

When is 2025-11-25 protocol version support expected? #800

Closed

Description

@devwhodevs

Problem

Downstream MCP servers built with rmcp cannot surface tools in Claude Desktop's Cowork and Code modes because these modes require protocolVersion: "2025-11-25", but rmcp 1.4.0 only supports up to "2025-06-18".

The MCP handshake completes successfully — the client proceeds through initialize → notifications/initialized → tools/list — and all 22 tools work in standard Claude Desktop chat and Claude Code CLI. But Cowork and Code-in-Desktop apply a stricter version filter and silently exclude servers negotiating older protocol versions.

Evidence

I maintain engraph, a Rust MCP server built on rmcp. A user reported this in devwhodevs/engraph#20 with full MCP logs showing:

  1. Client requests protocolVersion: "2025-11-25"
  2. Server (rmcp 1.4.0) responds with "2025-06-18"
  3. Handshake completes, tools listed, connection stays alive
  4. Tools work in standard chat — but not in Cowork or Code modes

Other MCP servers (TypeScript-based) negotiate "2025-11-25" and their tools appear in all modes.

Current state in rmcp

// model.rs (main branch)
pub const V_2025_06_18: Self = Self(Cow::Borrowed("2025-06-18"));
pub const LATEST: Self = Self::V_2025_06_18;

I see the 2025-11-25 Implementation project board tracks 18 rust-sdk items, and many SEPs have been merged. Only 3 SEP issues remain open (#526, #531, #527).

Question

Is there a rough timeline for when rmcp will declare 2025-11-25 protocol support? This is currently the only thing blocking Rust-based MCP servers from working in Claude Desktop's newer modes.

Not asking for a commitment — just trying to understand if it's weeks away or months, so downstream projects can plan accordingly.

Activity

  1. DaleSeo commented on Apr 10, 2026

    @DaleSeo
    Member

    Thanks for bringing this up, @devwhodevs! I don't think those SEPs are blocking us from supporting 2025-11-25 since they're all optional extensions or future proposals. I've created PR #802 to add support for the protocol version.

    @alexhancock @jamadeo Would it be okay if I remove the remaining open SEPs from the implementation project board? I don't see the same SEPs for the other SDKs, and I'm not sure how they were added in the first place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions