No public way for a client to request a specific protocol version

[JAORMX]

Is your feature request related to a problem? Please describe.

ClientSessionOptions.protocolVersion is unexported and documented as test-only (mcp/client.go:251):

type ClientSessionOptions struct {
	// protocolVersion overrides the protocol version sent in the initialize
	// request, for testing. If empty, latestProtocolVersion is used.
	protocolVersion string
}

So Client.Connect always requests latestProtocolVersion (mcp/client.go:313) and there is no public way for a consumer to request a specific revision. The SDK's own tests can, via the unexported field; external code cannot.

Describe the solution you'd like

Export it, or add an equivalent public option — e.g. ClientSessionOptions.ProtocolVersion string, keeping empty as "use the latest" so existing behaviour is unchanged.

Negotiation semantics need not change: the requested version would still be subject to the existing negotiate-down path, so a server that cannot serve it responds as it does today.

Describe alternatives you've considered

None available. The field is unexported and Connect takes no other version input, so a consumer cannot influence the requested version at all — including by wrapping or decorating, since the value is read inside Connect.

Additional context

Two concrete motivations, both from building a compatibility shim on top of this SDK:

1. Wrapping an API that accepts a requested version. Our shim exposes an mcp-go-shaped Initialize(ctx, InitializeRequest) whose params include a ProtocolVersion. Because the SDK offers no knob, the shim can only discard it — a caller asking for 2025-11-25 silently gets 2026-07-28 requested on the wire, with no error and no warning. Being unable to either honour or meaningfully reject the request is the awkward part: the least-bad option available to us is to document that the field does nothing.

2. Deliberately pinning an older revision. A proxy that must present a specific revision to a downstream peer, or an integration test asserting behaviour against a particular revision, currently cannot express that against a real client — which is presumably why the test-only field exists in the first place.

If exporting the existing field is acceptable I am happy to send a PR.

[JAORMX]

Flagging that this is a proposal by CONTRIBUTING's definition — it changes the signature of an existing exported type (ClientSessionOptions) — so it likely wants the proposal label and the associated maintainer review. I can't apply labels here; noting it so it lands in the right queue rather than sitting as a plain feature request.

I'm not going to send a PR ahead of that. Per CONTRIBUTING, non-'Help Wanted' issues should wait for maintainer confirmation, and proposals stay open at least a week for discussion. Happy to implement whichever shape you settle on — exporting the existing field is the smallest change, but if you'd rather it were a distinct option type or a method on the client, that's your call to make, not mine to pre-empt.

One clarification in case it affects the shape: the case that motivates this for us doesn't need to force a version, only to request one and let the existing negotiate-down path do its job. If a narrower "requested floor/preference" API is more palatable than a general override, that would serve us equally well.

[guglielmo-san]

@JAORMX your request make sense, PR #1127 should fix this