| Filename | Latest commit message | Latest commit date |
|---|---|---|
a0ce1f89be
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> |
||
| .. | ||
| .env.example | ||
| go.mod | ||
| go.sum | ||
| main.go | ||
| README.md | ||
An LLM-Powered Chatbot MCP Client written in Go
See the Build an MCP client tutorial for more information.
Structured content
The SDK does not validate tool output, so this client compiles each declared outputSchema at connect time and checks results against it — the spec's client-side SHOULD. It uses jsonschema-go, already an SDK dependency.
The two channels go to different readers: Content is forwarded to the model, while StructuredContent is used as data — the client counts the items it returns. See Structured Content.