The License section named MIT. LICENSE is a transition file: new code
contributions are Apache-2.0, documentation excluding specifications is
CC-BY-4.0, and only earlier contributions without relicensing consent
stay MIT.
"Rust (stable)" understates the floor. rmcp, darling and time declare
rust-version 1.88, and cargo metadata resolves both crates to 1.88.
The Ruby aside said 3.3 also satisfies the gems. anthropic requires
>= 3.2.0 and mcp >= 2.7.0, so the gem floor was 3.2, and 3.2 reached EOL
on 2026-03-31. CI runs 3.4, which is what the READMEs now state.
The Go and Rust clients take a command plus arguments, not a path to a
server script.
Removed the commit-message convention, which is attributed to the MCP
contributing guidelines but does not appear in them. Added the
AI_POLICY.md link that CONTRIBUTING.md points to.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GdvHa5MzDw33PEz3DbTaJD
The surrounding sentence names 2026-07-28 as the revision that first allows
an array-rooted schema, but the link pointed at /draft, which moves on to
the next revision and stops matching the claim.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Both tools declare an output_schema and return structured_content alongside
the text.
get_alerts declares Vec<Alert>, so it answers with a top-level JSON array
rather than an array nested in an object, which protocol revision 2026-07-28
is the first to allow. "No alerts" is simply []. get_forecast returns an
object, for contrast.
Error paths return a tool-level error: a tool declaring an output_schema MUST
return conforming structured content, so a path with no data has to fail.
The client compiles every declared outputSchema at connect time and validates
results against it. rmcp does not do this; its docs point at the jsonschema
crate, which is the one new dependency here. Each channel goes to its stated
reader: content is forwarded to the model, structured_content is used as data,
reporting how many items came back. A missing .env is no longer fatal, and the
API key is checked after connecting rather than before.
This supersedes #143, which bumped rmcp 0.3 -> 1.4 and failed CI because the
0.3 #[tool] macro API does not survive the jump. The rewrite was required
either way, so the bump is folded in and taken to 3.0.0-beta.2, the first
version with the 2026-07-28 model.
list_tools is hand-written. #[tool_handler] generates one hardcoding
ttl_ms: None, cache_scope: None, but both are required on a paginated result
at 2026-07-28 (SEP-2549) and a strict client rejects the response outright.
get_info does not pin ProtocolVersion::V_2026_07_28 either: rmcp's server
never implements server/discover, so pinning would overstate support.
Model identifier moves to claude-sonnet-5, replacing claude-sonnet-4-20250514,
which is past end of life.
Note that rmcp sends an array-rooted schema as written on every connection
rather than projecting it down, so an older client rejects the tool list.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
