WorkerTransport doesn't persist clientCapabilities, breaking elicitation in serverless

[mattzcarey]

Description

When using WorkerTransport with storage for MCP in a serverless environment (like Cloudflare Workers), the client capabilities are not persisted across requests. This causes elicitation to fail with:

Error: Client does not support form elicitation.
    at Server.elicitInput

Root Cause

The TransportState interface only stores:

export interface TransportState {
  sessionId?: string;
  initialized: boolean;
}

However, _clientCapabilities is stored on the Server instance and set during the initialize request. When a new serverless function instance handles a subsequent request (like a tool call that triggers elicitation), the capabilities are lost because:

1. The transport state is restored from storage ✅
2. But _clientCapabilities on the Server instance is not restored ❌

Steps to Reproduce

1. Create an MCP server using WorkerTransport with storage
2. Register a tool that uses server.elicitInput()
3. Connect a client that advertises elicitation capability
4. Call the tool - elicitation fails because capabilities weren't persisted

Expected Behavior

Client capabilities should be persisted as part of the transport state so they survive across serverless function invocations.

Suggested Fix

Include clientCapabilities in TransportState:

export interface TransportState {
  sessionId?: string;
  initialized: boolean;
  clientCapabilities?: ClientCapabilities; // Add this
}

And restore them when handling requests after initialization.

Environment

• @modelcontextprotocol/sdk: 1.25.2
• agents: latest
• Runtime: Cloudflare Workers (wrangler dev)