Summary
Support MCP 2026-07-28 per-request metadata while preserving initialize-based clients.
Problem
Modern MCP requests select protocol behavior through request metadata, while existing ICM clients negotiate through initialize. Accepting malformed metadata or switching protocol eras during a connection would produce ambiguous behavior.
Desired outcome
Support both protocol eras with strict modern validation, stable connection behavior, useful discovery metadata, and actionable incompatibility errors.
Acceptance criteria
- support
2026-07-28 alongside the existing supported revisions
- require valid modern
_meta, protocolVersion, and clientCapabilities
- validate optional client identity fields
- lock each connection to one protocol era
- expose discovery, capability, cache, and server metadata
- return an actionable error for unsupported versions
- preserve MCP
2024-11-05 request and response shapes
Related work
Summary
Support MCP
2026-07-28per-request metadata while preserving initialize-based clients.Problem
Modern MCP requests select protocol behavior through request metadata, while existing ICM clients negotiate through
initialize. Accepting malformed metadata or switching protocol eras during a connection would produce ambiguous behavior.Desired outcome
Support both protocol eras with strict modern validation, stable connection behavior, useful discovery metadata, and actionable incompatibility errors.
Acceptance criteria
2026-07-28alongside the existing supported revisions_meta,protocolVersion, andclientCapabilities2024-11-05request and response shapesRelated work