[v2] Expose the JSON-RPC request id to callers of request() (onRequestId) #3061

Summary

Protocol.request() assigns the JSON-RPC id internally (this._requestMessageId++) and never exposes it to the caller. An extension that opens a long-lived request, and then receives notifications correlated to that request, can't tell which request a given notification belongs to.

Why it matters

In the Events extension (SEP-3415, see #2945), a client may hold several events/stream requests open at once. Each stream starts with a notifications/events/active that confirms the subscription. On transports without per-request streams (stdio), the client needs the request id to match that notification to the open that produced it.

In @mastra/mcp we first bound each open to the first unclaimed active notification. That can mismatch subscriptions when one confirmation arrives late after a timeout. We now work around it by wrapping transport.send to observe the outgoing message and read its id. That relies on internal envelope details.

Proposal

Expose the id through a RequestOptions callback, for example onRequestId?: (id: RequestId) => void, invoked synchronously before the message is sent. An alternative would be a lower-level API that returns { id, result } for the request.

Versions

We hit this on @modelcontextprotocol/client@2.2.0. It's still present on main (c05225a6), in _requestWithSchemaViaCodec in packages/core-internal/src/shared/protocol.ts.