The spec never uses the phrase "structured output". It defines two separate things under Tool Result: "Structured Content" (the `structuredContent` field) and "Output Schema" (the `outputSchema` field). Collapsing them into "structured output" conflates the two. It is also actively confusing here. In LLM tooling "structured output" means constrained decoding — making the *model* emit conforming JSON. These clients call a model API, so a reader could reasonably take the phrase to mean the tool constrains the model's response, which is the opposite of what is going on: the tool describes the shape of its own result. Headings and prose now say "structured content". References to real identifiers are left alone: the Python SDK's own docs page is called Structured Output and lives at docs/servers/structured-output.md, and its decorator parameter is `structured_output`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.3 KiB
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 content
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.