| 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 | ||
A Simple MCP Weather Server written in Rust
See the Build an MCP server tutorial for more information.
Structured content
Both tools declare an output_schema and return structured_content. 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.
Note that an array-rooted schema requires a 2026-07-28 client: rmcp sends it as written on every connection rather than projecting it down, so an older client rejects the tool list.
list_tools is hand-written because #[tool_handler] omits the SEP-2549 ttl_ms and cache_scope fields, which are required on a paginated result at this revision.