Strip reserved io.modelcontextprotocol/* keys from backend response _meta (shared Legacy+Modern helper)

[jhrozek]

Part of #5756. Source: a follow-up flagged in-code at pkg/vmcp/server/modern_envelope.go (newModernResultMeta, ~line 72-76) and its Legacy sibling conversion.ToMCPMeta (pkg/vmcp/conversion/meta.go, used from serve_handlers.go / pkg/vmcp/client/client.go).

Problem

On the response path (backend → client), both revisions forward all backend _meta keys unfiltered — including reserved io.modelcontextprotocol/* keys:

• Modern (newModernResultMeta) clones backend meta and overwrites only io.modelcontextprotocol/serverInfo, forwarding every other reserved key untouched.
• Legacy (conversion.ToMCPMeta) does the same (the Modern code comment explicitly notes it matches this sibling).

So a backend can set other reserved keys (protocolVersion, clientCapabilities, or any future io.modelcontextprotocol/* key) on a tools/call/tools/list/resources/read result and have them reach the vMCP client as if vMCP set them. vMCP — not the backend — is the client's MCP peer, so vMCP must own the reserved namespace on responses. The merged code already recognized this for serverInfo ("vMCP's own serverInfo must win") but deliberately punted the general case.

Changes

• Strip/normalize reserved io.modelcontextprotocol/* keys from backend response _meta before forwarding to the client.
• Do it in one helper shared by the Legacy (conversion.ToMCPMeta/serve_handlers) and Modern (newModernResultMeta) paths — not in one only, or "Legacy and Modern would drift" (the explicit warning in the modern_envelope.go comment).
• Preserve non-reserved backend meta (progress tokens, trace ids, …); keep vMCP's own serverInfo authoritative.

Note — the request-path mirror already exists

The client edge (request path, client → backend) already strips reserved keys in #5980's ModernRequestMeta ("single source of truth for the client side of the reserved _meta"). This issue is the response-path counterpart; it should share a home with (or at least mirror) that logic rather than add a third independent copy.

Verification

• A backend that sets io.modelcontextprotocol/protocolVersion (or any reserved key) on a result does not leak it to the client — on both the Legacy and Modern paths.
• vMCP's own serverInfo remains authoritative.
• Non-reserved backend meta is preserved unchanged.
• One shared helper covers both revisions (a regression test pinning that both paths call it).

[jhrozek]

Note for whoever implements this — a trap in the "one shared helper" framing, found while building
the cross-generation bridge (#6006).

conversion.ToMCPMeta is bidirectional. It is not a response-path function, so putting the strip
inside it would also strip on the outbound request path:

Response path (backend → client), which this issue wants stripped:

• pkg/vmcp/server/serve_handlers.go:310,426
• pkg/vmcp/server/adapter/handler_factory.go:117,209
• pkg/vmcp/server/sessionmanager/factory.go:241
• pkg/vmcp/codemode/decorator.go:371

Request path (vMCP → backend), which must not get response-path rules:

• pkg/vmcp/client/client.go:1687,1867,1988 — these wrap telemetry.MetaWithTraceContext(ctx, …),
  i.e. they are adding outbound _meta, and the egress already has its own rule in
  StripReservedModernMeta at the Legacy tool-call egress.

So the shared helper should be applied at the response-path call sites (or via a response-specific
wrapper), leaving ToMCPMeta as the direction-agnostic type converter it currently is. The Modern
side (newModernResultMeta, pkg/vmcp/server/modern_envelope.go:78) is unambiguous — it is
response-only.

Two things to assert, not one. #6006 hit the mirror image of this on the request path and it is
worth copying the lesson: a test that only asserts reserved keys are absent also passes when
_meta arrives empty or is dropped wholesale, which would silently kill progressToken and trace
context. So assert both directions — reserved keys stripped and a non-reserved key surviving the
same hop. Mutation testing catches the first but structurally cannot catch the second, since it only
exercises the direction where keys wrongly appear.

No conflict with #6006. Its bridge pins (pkg/vmcp/server/bridge_regression_test.go) deliberately
assert nothing about response _meta, specifically to leave this clean — so this can be worked in
parallel on top of main without waiting for that PR.

Also relevant: #6002 notes that ReservedModernMetaKeys currently does double duty as both the
egress strip-list and the ingress "this request claims Modern" signal, and wants those split before
logLevel is added. If both land, the response-path strip should consume the strip-list half.