| Filename | Latest commit message | Latest commit date |
|---|---|---|
f24bf97412
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 | ||
| client.rb | ||
| Gemfile | ||
| README.md | ||
An LLM-Powered Chatbot MCP Client written in Ruby
See the Build an MCP client tutorial for more information.
Structured content
The spec says clients SHOULD validate structured results against the schema the tool declares, and this SDK's client does not do it for you — MCP::Client::Tool#output_schema hands back the raw schema from the wire and nothing checks results against it. So the client compiles each declared schema once at connect time with MCP::Tool::OutputSchema.new and validates every non-error result.
The two channels go to different readers: content is forwarded to the model, while structured_content is used as data — when a tool returns an array, the client counts its items rather than re-reading the prose. See Structured Content.
MCP::Client::Stdio offers 2026-07-28 by default, so no negotiation setup is needed here.