| Filename | Latest commit message | Latest commit date |
|---|---|---|
v1.7.0 shipped on 2026-07-27, so the pin moves off v1.7.0-pre.3. Removes mcp-client-go.exe and weather-server-go/weather.exe, which were committed by accident in the previous commit — 14MB of build output that should never have been in the tree. The tests branch adds the ignore rules that keep them out. Also from review: the server README claimed both tools set an OutputSchema. Only get_alerts does; get_forecast relies on inference from the handler return type, which is the idiomatic spelling and worth saying so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
| .. | ||
| go.mod | ||
| go.sum | ||
| main.go | ||
| README.md | ||
A Simple MCP Weather Server written in Go
See the Build an MCP server tutorial for more information.
Building
go build -o weather
Running
./weather
The server will communicate via stdio and expose two MCP tools:
get_forecast- Get weather forecast for a location (requires latitude and longitude)get_alerts- Get weather alerts for a US state (requires two-letter state code)
Structured output
Both tools advertise an outputSchema and return StructuredContent. get_forecast returns an object; get_alerts returns a top-level JSON array, which protocol revision 2026-07-28 is the first to allow — see Structured Content in the spec.
get_forecast sets no OutputSchema on the Tool: the SDK infers one from the handler's return type, which is the idiomatic Go spelling. get_alerts overrides it, because inference widens a slice to ["null", "array"] — a nil slice marshals to null — and the tool never returns nil.
Note that an array-rooted schema requires a 2026-07-28 client: the SDK sends it as written on every connection rather than projecting it down, so an older client rejects the tool list.