fix: sanitize tool input_schema for Anthropic adapter#4346
Conversation
When configuring Anthropic as the provider, any tool whose input_schema contains a top-level oneOf/anyOf/allOf causes the API to reject the entire request with HTTP 400: Anthropic API error (HTTP 400 Bad Request invalid_request_error): tools.1.custom.input_schema: input_schema does not support oneOf, allOf, or anyOf at the top level The OpenAI Responses adapter already handles this via schema_sanitize::sanitize_for_responses, which strips root-level composition keywords, merges alternative properties into the root object, and surfaces dropped constraints as a description note so the model still knows which parameters are expected. Apply the same sanitization in the Anthropic adapter before sending tool definitions, aligning both adapters for consistent schema handling across providers.
|
Thanks @qinlinwang for taking the time to contribute. This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered. Please read |
When configuring Anthropic as the provider, any tool whose input_schema contains a top-level oneOf/anyOf/allOf causes the API to reject the entire request with HTTP 400: Anthropic API error (HTTP 400 Bad Request invalid_request_error): tools.1.custom.input_schema: input_schema does not support oneOf, allOf, or anyOf at the top level The OpenAI Responses adapter already handles this via schema_sanitize::sanitize_for_responses, which strips root-level composition keywords, merges alternative properties into the root object, and surfaces dropped constraints as a description note so the model still knows which parameters are expected. Apply the same sanitization in the Anthropic adapter before sending tool definitions, aligning both adapters for consistent schema handling across providers. Harvested from PR #4346 by @qinlinwang
Summarize the underwater interaction system, treatment/motion independence, compact-room fixes, footer notice ownership, ASCII tier, and localization parity work in the 0.8.68 changelog section, and credit the harvested community work: Korean locale (PR #4347 @moduvoice), Anthropic schema sanitization (PR #4346 @qinlinwang), Anthropic cache-write pricing (PR #4348 @knqiufan), NetBSD bindgen (PR #4349 @ci4ic4), and the #4208 copy-pollution report (@eugenicum).
|
Thanks @qinlinwang — your contribution landed in
Closing this PR now that the code is on If you want to land more work and would prefer your future PRs merge cleanly without a harvest step, the |
1 participant
Summary
When using Anthropic as the provider, any tool whose
input_schemacontains a top-level
oneOf/anyOf/allOfcauses the API to rejectthe entire request with HTTP 400:
This makes the Anthropic provider completely unusable whenever a tool
definition includes composition constraints - which is the case for
several built-in tools.
Root cause: The Anthropic adapter (
crates/tui/src/client/anthropic.rs)passes
tool.input_schemato the API as-is, without sanitizingtop-level composition keywords. The OpenAI Responses adapter
(
crates/tui/src/client/responses.rs:596-611) already solves this bycalling
schema_sanitize::sanitize_for_responses, which:oneOf/anyOf/allOfstill knows which parameters are expected
Fix: Apply the same
sanitize_for_responsescall in the Anthropicadapter before sending tool definitions, aligning both adapters for
consistent schema handling across providers.
Testing
cargo fmt --all -- --checkcargo clippy --workspace --all-targets --all-featurescargo test --workspace --all-featuresChecklist