| Filename | Latest commit message | Latest commit date |
|---|---|---|
`#[tool_handler]` generated `ttl_ms: None, cache_scope: None`, but both are required on a paginated result at 2026-07-28, so a strict client rejected tools/list before it could reach a tool call. The server worked around that by hand-writing list_tools purely to set the two fields. rust-sdk#1120 fixed the macro, released in rmcp 3.1.1: it now emits the fields when the negotiated revision expects them and omits them otherwise. Both lockfiles move to 3.1.2 and the override goes away, so the server is back to the plain `#[tool_handler]` path the SDK documents. Verified on the raw wire: after a 2026-07-28 handshake, tools/list carries `ttlMs: 0` and `cacheScope: "public"` with no code setting them, and the smoke test's strict client still validates both tools' structured content. |
||
| .. | ||
| 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.