* Fix the tool-use loop in the Go, Rust, and Ruby clients and add a tool-loop smoke test
## Motivation and Context
Only the Python and TypeScript clients implemented a correct tool-use loop. The other three
had bugs that break ordinary multi-step requests:
- **Go, Rust, Ruby** did a single tool round and then called Claude once more *without*
`tools`, so any request that needs a second tool call stalled. Go silently dropped
`tool_use` blocks from that final response.
- **Ruby** called Claude once per `tool_use` block, each time with a single `tool_result`.
Parallel tool calls produced a malformed message sequence and an API 400.
- **max_tokens** was 1000 in TypeScript and Ruby, 1024 in Go, and unset in Rust. Sonnet 5
thinks adaptively, so 1000 tokens is regularly exhausted mid-thought. Python already used
10000 with a comment explaining why.
- **Ruby** never forwarded MCP `isError` as `is_error`, so the model could not tell a failed
tool call from a successful one. Rust cannot set the flag either (see below).
- **TypeScript** forwarded raw MCP content blocks to Anthropic. The two block shapes differ,
so a non-text result would have failed.
The existing smoke test never noticed because it only checks that each client calls
`tools/list`. None of these bugs was reachable without an API key.
### What changed
All five clients now run the same loop: call tools until Claude answers without one, send
every `tool_result` of a turn in one user message, pass `tools` on every call, and stop
after `MAX_TOOL_TURNS = 10`. `max_tokens` is 10000 everywhere, with the same comment.
Python and TypeScript also keep the last response's text when the turn cap is hit; it used
to be dropped.
Rust keeps the `genai` crate. Its tool-response type has no `is_error` field, so an error
result is marked with an `Error:` prefix in the text and the limitation is commented.
### New smoke test
`tests/helpers/tool-loop-test.ts` starts a fake Anthropic Messages API on a loopback port,
points a client at it through `ANTHROPIC_BASE_URL`, pipes in one query, and checks every
request the client sends. It scripts two parallel tool calls, then a call to a tool the mock
server lacks (an `isError` result), then a final answer, and asserts that tools are passed
each time, `max_tokens` is 10000, all `tool_result`s arrive in one message with matching
ids, and the error is forwarded. `smoke-test.sh` runs it for Python, TypeScript, Go, and
Ruby.
The Rust client is excluded for now: `genai` reads no endpoint variable, and the client
negotiates protocol `2025-11-25`, under which the mock's array-rooted tool is refused at call
time. Both will be addressed in a follow-up that brings all examples to current SDK versions.
## How Has This Been Tested?
- `./tests/smoke-test.sh` passes for every example.
- The new tool-loop test passes all 19 checks for Python, TypeScript, Go, and Ruby.
- The Rust client was driven through the same scripted conversation with a temporary
endpoint resolver (not committed) and passes.
- As a negative check, the Ruby client from `main` was run through the new test. It fails 10
of 19 checks, on exactly the bugs listed above.
- Go and Ruby were built and run in `golang:1.25` and `ruby:3.4` containers.
## Breaking Changes
None. The clients' command lines, output format, and no-key behavior are unchanged.
## Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [x] Documentation update
## Checklist
- [x] I have read the [MCP Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
Two pre-existing issues surfaced while testing and are left for a follow-up:
- The Rust client (rmcp 3.1.2) negotiates `2025-11-25`. The TypeScript mock server and the
Python weather server both reject its calls to array-rooted tools under that revision.
Even current rmcp defaults to `2025-11-25`, so the client must request `2026-07-28`
explicitly.
- The Go SDK's tool-result helper sends content as a list of text blocks rather than a
string. The API accepts both, so it is unchanged.
AI assistance: the analysis, code changes, test helper, and this description were prepared
partially manually, partially with Claude Code and reviewed by me.
* Improvements
* Address comments
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>
The mcp gem 1.1.0 (2026-08-01) is the first to negotiate 2026-07-28, so the
Ruby examples can finally show the same thing the other four do: get_alerts
declares an array-rooted output_schema and returns a bare top-level JSON
array, get_forecast returns an object. Declaring `type:` at the root is what
suppresses the SDK object-root default.
Failure paths return an error result rather than a bare text one, because a
tool declaring an output_schema MUST return conforming structured content.
No alerts is an empty array, not an error.
The client compiles each declared schema at connect time and validates every
non-error result. The SDK client does not do this itself, so the spec
client-side SHOULD costs real code here, as it does in Go and Rust.
NOT READY TO SHIP. The gem never emits the `resultType` field that the
2026-07-28 schema marks mandatory, and no user-level knob sets it, so a
spec-strict client rejects every response including tools/list. Verified
end-to-end against the Ruby client, which does not check the field; blocked
against the TypeScript SDK client. See the server README.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
## Motivation and Context
Follow-up to https://github.com/modelcontextprotocol/ruby-sdk/pull/336
mcp gem 0.15.0 introduced an explicit `MCP::Client#connect` method for the stdio transport,
aligning with the Python and TypeScript SDKs which require explicit handshake calls regardless
of transport type:
- Python SDK: `ClientSession.initialize()`
https://github.com/modelcontextprotocol/python-sdk
- TypeScript SDK: `Client.connect(transport)`
https://github.com/modelcontextprotocol/typescript-sdk
This sample is updated to call `@mcp_client.connect` explicitly after creating the client,
demonstrating the recommended initialization pattern. The Gemfile constraint is bumped to `>= 0.15.0`
to require the new API.
## How Has This Been Tested?
Ran the sample against `weather-server-ruby` and confirmed the connection, tool listing,
and chat loop continue to work as expected.
## Breaking Changes
None. The change updates the sample to use the new explicit `connect` API,
which was added as a non-breaking addition in mcp gem 0.15.0.
