experimental-ext-variants

Summary merges map entries from inner variant servers but skips the field entirely. This means any extension registered via on an inner server (e.g. ) is silently dropped from the front proxy's . Add the same first-wins merge logic for that already exists for Bump to v1.4.1 which introduced the field on Add unit test for extensions merging Add integration test verifying extensions survive the variant path end-to-end Test plan [x] — verifies first-wins merge semantics for extensions [x] — verifies extensions registered on inner servers appear in the client's [x] All existing tests pass (27/27)

Simplify variant dispatch and session by replacing per-method boilerplate with generic handlers backed by reflect. Motivation and Context The dispatcher and backend session had separate handler functions for every MCP method (ListTools, ListResources, CallTool, Subscribe, etc.), each following an identical pattern: extract params, inject metadata, call inner handler, cast result. This meant ~250 lines of near-identical code across dispatch.go and session.go, and every new MCP method required adding another copy. How Has This Been Tested? All existing unit and integration tests pass (go test -v ./...) Breaking Changes None. All changes are internal to the variants package. Public API is unchanged. Types of changes Refactor (non-breaking change which fixes an issue)

Registers a sending middleware on each inner server that intercepts all outgoing messages and routes them through the front session using a session-swapped request wrapper. Replaces the previous proxy client handler approach which dropped log messages in stateless mode. Motivation and Context Tool handlers in variant servers use req.Session (the inner session) to send notifications. Previously, log messages were silently dropped in stateless mode because the inner session is not aware of the front session. This change injects the sendingMethodHandler from the frontSession into the context and adds a sending middleware to redirect all sending requests to the frontSession handler directly. A few considerations in this implementation: Having frontSession in the context allows notifications to be sent to the correct frontSession, when the same backend session could be used by multiple front sessions. This solution will work for synchronous notifications that happen within the same context (progress, log, sampling, elicitation) but not working for asynchronous notifications (tool list changed, resource updated etc), because asynchronous notifications are sent with a new context. All the operations before the sending method will still happen in the backend. Most notable impact is in stateless mode, requests from one client could change the log level for other clients. For this reason, I default the logging level to debug for now. This implementation relies on the MCP Go SDK sendingMethodHandler taking a generic not one that tied to specific function. Based on the current SDK implementation this is unlikely to change. The same generic method forwarding mechanism could work for receiving methods too, but with some caveat. That can be addressed in separate PR. How Has This Been Tested? TestNotificationDelivery — verifies progress and log messages arrive at the front clients with multiple clients making concurrent request. New tests added for context preservation that was added in https://github.com/modelcontextprotocol/experimental-ext-variants/pull/6. Context preservation is required to make the notification forwarding work anyway. Since we use the context to carry frontSession handler to the backend session. All existing tests pass Breaking Changes None. Tool handlers continue to use req.Session normally. Types of changes Bug fix (non-breaking change which fixes an issue)