Coding agents write Go the way it was written when their training data was assembled, which means hand-rolled helpers where `slices` and `maps` now exist. Handing the model a version-scoped changelog is a cheap fix for that. The size warning is real — filter to the package you are working in rather than asking for everything since 1.13.
A single-purpose reference server carrying Go release information from 1.13 through 1.24 — 12 versions — embedded in the binary. Ask it what changed since the version you are on, optionally narrowed to one standard library package, and it returns structured Markdown covering language features, standard library additions, runtime and toolchain changes, and upgrade guidance.
- `go-updates` — the one tool, taking a required `version` between "1.13" and "1.24" and an optional `package` to filter to one standard library package such as net/http, slices, maps or log/slog
- Output shaped for a model rather than a human: hierarchical headings, a summary of impact, chronological version sections, and code examples in fenced blocks
- Everything embedded with go:embed, so the server is a single binary with no data files to ship alongside it
Nothing — no account, no key. Go, with the documented client entry running `go run github.com/tenkoh/recent-go-mcp@latest`; `go install` and registering the binary path works too. It speaks stdio. The author flags two things: the release data was largely written with an LLM's help and may contain mistakes, and the unfiltered output can be too large for some hosts — using the `package` filter is the practical answer until pagination lands.
Build from source — clone the repository and build it, then point your client at the binary