Move off the go-sdk v1.7.0 pre-release once it goes final

[JAORMX]

Part of #5743. Split out of #6002 (item 8) so that issue can close — this one waits on an external release and has no in-repo work until then.

Context

go.mod currently pins:

github.com/modelcontextprotocol/go-sdk v1.7.0-pre.3 // indirect

It is indirect, arriving via toolhive-core.

Why this needs tracking rather than Renovate

renovate.json extends config:recommended, which sets ignoreUnstable: true. Renovate will therefore never propose moving off a pre-release — so the only exit is a deliberate toolhive-core bump. Left alone, this pin is silently permanent.

Unlike other pre-release pins in the tree (e.g. swaggo/swag's rc5, which is codegen tooling), go-sdk is on the runtime wire path: it is what actually speaks MCP to clients and backends.

Work

• Track go-sdk reaching v1.7.0 final.
• Bump toolhive-core onto it, then bump ToolHive onto that toolhive-core.
• Review the v1.7.0 changelog for wire-behaviour changes between pre.3 and final, particularly anything touching server/discover, supportedVersions semantics, or the Modern result envelope — pkg/vmcp/client/modern.go and pkg/vmcp/server/modern_envelope.go mirror shapes observed in pre.3 (see Retire the hand-rolled Modern wire shim in vMCP #6018).
• Also evaluate the MCPGODEBUG escape hatches, which go-sdk removes in v1.9.0.

TestProbeRevision_RealBackends runs against a real go-sdk backend, so it should be the first place a supportedVersions semantic change surfaces.

Generated with Claude Code

[JAORMX]

Landmine for whoever does this bump

Adding this here because the person doing the next go-sdk / toolhive-core bump is exactly the person positioned to trip it.

ToolHive's Legacy→Modern revision self-heal currently depends on go-sdk ignoring the protocol version we ask for.

mcpcompat.LATEST_PROTOCOL_VERSION is "2025-11-25", and all three production initialize paths pass it:

• pkg/transport/bridge.go:197
• pkg/vmcp/client/client.go:852
• pkg/vmcp/session/internal/backend/mcp_session.go:553

But mcpcompat/client.Initialize calls go-sdk's Connect(ctx, tr, nil), which discards that and requests go-sdk's own latest — 2026-07-28. A Modern-capable backend therefore answers initialize with 2026-07-28, which is precisely how legacyInit detects a mis-cached backend and flips its revision cache Legacy→Modern (#5997, pinned by TestListCapabilities_MisCachedLegacy_SelfHealsViaSDKNegotiation).

So if a future bump combines:

1. go-sdk#1113 landing a public way to request a protocol version, and
2. mcpcompat starting to honour Params.ProtocolVersion

…then those three call sites begin genuinely requesting 2025-11-25, Modern-capable backends negotiate down, the self-heal never fires, and vMCP's Legacy→Modern correction regresses silently — the cache just stays wrong, which per #5992 is an operator-facing status inaccuracy rather than a hard failure, so CI may well stay green apart from that one test.

The fix at that point is to stop passing LATEST_PROTOCOL_VERSION at those three sites (or pass 2026-07-28), not to revert the shim. Tracked from the toolhive-core side in stacklok/toolhive-core#193, which records this as an explicit non-goal for the same reason.

Related upstream issues

Filed while investigating this, both relevant to the bump:

• go-sdk#1112 — the SSE transport advertises 2026-07-28 in server/discover despite that revision defining only stdio and Streamable HTTP. No ToolHive impact today (vMCP's Modern egress only POSTs to the configured BaseURL), but it is the reason pkg/mcp/parser_integration_test.go can observe Modern negotiation over an sse-labelled endpoint while probeRevision asserts that cannot happen — both correct, different layers.
• go-sdk#1113 — no public way to request a specific protocol version. This is a proposal upstream, so it carries a minimum one-week discussion window before it can even be accepted.

Neither blocks reaching v1.7.0 final; both are worth re-reading when the bump happens.