Tracking the MCP go-sdk upgrade that dependabot proposed in #62 (1.6.1 → 1.8.0). It is not a drop-in bump for this project, measured on a local build of that PR:
- Release module set. 1.7+ links
golang.org/x/time into the binary, a module the release does not carry today, so THIRD-PARTY-NOTICES, the license inventory gate, and the supply-chain documents all change. That is a deliberate supply-chain decision, not a version bump.
- Wire shape.
tools/list results gain ttlMs and cacheScope. Additive, but it is a visible change to a response this project pins with a golden and a conformance suite.
- Protocol revision. 1.7 enables the
2026-07-28 stateless protocol by default for peers that offer it. None of the four black-box suites speaks that revision, so it would ship unexercised. 1.8 adds ServerOptions.SupportedProtocolVersions, which is the right tool: adopt the SDK and pin the revisions the suites cover, then widen deliberately with a harness arm for the new one.
- Security. No published advisory applies to 1.6.1 (all are fixed at or before 1.4.1). 1.8.0's hardening (bounded decoding, nesting limits) is defence in depth for a local stdio server.
The PR's red CI is the known pattern for dependency PRs here (go.mod is a governed source, so conformance sees an unaligned repository); a binary built with 1.8.0 passes conformance 46/46 against an aligned repository.
Plan for the 0.2.0 line: bump to the then-current SDK, pin supported protocol versions, add a harness arm for 2026-07-28, update the notices and the driver/module documentation in the same change, and let the upgrade axis prove existing repositories stay governable.
Tracking the MCP go-sdk upgrade that dependabot proposed in #62 (1.6.1 → 1.8.0). It is not a drop-in bump for this project, measured on a local build of that PR:
golang.org/x/timeinto the binary, a module the release does not carry today, soTHIRD-PARTY-NOTICES, the license inventory gate, and the supply-chain documents all change. That is a deliberate supply-chain decision, not a version bump.tools/listresults gainttlMsandcacheScope. Additive, but it is a visible change to a response this project pins with a golden and a conformance suite.2026-07-28stateless protocol by default for peers that offer it. None of the four black-box suites speaks that revision, so it would ship unexercised. 1.8 addsServerOptions.SupportedProtocolVersions, which is the right tool: adopt the SDK and pin the revisions the suites cover, then widen deliberately with a harness arm for the new one.The PR's red CI is the known pattern for dependency PRs here (go.mod is a governed source, so conformance sees an unaligned repository); a binary built with 1.8.0 passes conformance 46/46 against an aligned repository.
Plan for the 0.2.0 line: bump to the then-current SDK, pin supported protocol versions, add a harness arm for
2026-07-28, update the notices and the driver/module documentation in the same change, and let the upgrade axis prove existing repositories stay governable.