| Filename | Latest commit message | Latest commit date |
|---|---|---|
506e1f70de
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> |
||
| .. | ||
| src | ||
| Cargo.lock | ||
| Cargo.toml | ||
| README.md | ||
An LLM-Powered Chatbot MCP Client written in Rust
See the Build an MCP client tutorial for more information.
Structured content
rmcp 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 the jsonschema crate, which rmcp's own documentation recommends.
The two channels go to different readers: content is forwarded to the model, while structured_content is used as data — the client counts the items it returns. See Structured Content.