Part of #1128. Prerequisite for the MCP 2026-07-28 stateless server.
Context and motivation
The legacy server stores a v1 InitializeRequest and passes it through mode resolution, UI detection, request-origin selection, report-problem gating, and telemetry. MCP 2026-07-28 supplies the same client data on every request through the v2 SDK context. Shared logic must not depend on either SDK request type.
Scope
In scope
- Add a plain client-context type containing protocol version, client identity, and capabilities.
- Convert the legacy
InitializeRequest into that context at the legacy adapter boundary.
- Make server-mode resolution, UI detection, request-origin selection,
report-problem gating, and telemetry consume the neutral context.
- Keep
initializeRequestData compatibility for existing callers and normalize it immediately.
- Keep current legacy wire behavior unchanged.
Out of scope
- Adding v2 SDK dependencies or a stateless server.
- Moving protocol handlers out of
ActorsMcpServer.
- Deleting
add-actor.
Technical design
The neutral context uses plain data and imports neither MCP SDK generation. Existing v1-facing code performs one conversion from InitializeRequest; the later stateless adapter will perform its own conversion from ServerContext. Helpers consume the normalized context instead of reconstructing client data from SDK request objects.
Do not add a general request abstraction for auth, notifications, or transports in this PR.
Internal repo impact
No internal changes expected. Existing session recovery may continue supplying initializeRequestData; the public server normalizes it internally.
Testing strategy
- Keep the existing capability-gating, report-problem, request-origin, and client tests green without changing their behavior assertions.
- Add direct tests for missing client data, UI capabilities, blocked client names, APIFY AI origin, and telemetry field projection.
Verification checklist
Part of #1128. Prerequisite for the MCP 2026-07-28 stateless server.
Context and motivation
The legacy server stores a v1
InitializeRequestand passes it through mode resolution, UI detection, request-origin selection,report-problemgating, and telemetry. MCP 2026-07-28 supplies the same client data on every request through the v2 SDK context. Shared logic must not depend on either SDK request type.Scope
In scope
InitializeRequestinto that context at the legacy adapter boundary.report-problemgating, and telemetry consume the neutral context.initializeRequestDatacompatibility for existing callers and normalize it immediately.Out of scope
ActorsMcpServer.add-actor.Technical design
The neutral context uses plain data and imports neither MCP SDK generation. Existing v1-facing code performs one conversion from
InitializeRequest; the later stateless adapter will perform its own conversion fromServerContext. Helpers consume the normalized context instead of reconstructing client data from SDK request objects.Do not add a general request abstraction for auth, notifications, or transports in this PR.
Internal repo impact
No internal changes expected. Existing session recovery may continue supplying
initializeRequestData; the public server normalizes it internally.Testing strategy
Verification checklist
pnpm run type-checkpnpm run lintpnpm run test:unitpnpm run formatpnpm run check:agents