A flight-booking tool's schema requires `passengers` to be a JSON integer. Without any special configuration, Claude sometimes returns `passengers: "2"` (a string) or `passengers: "two"` instead of the integer `2`, which breaks the booking function expecting a number. Setting `strict: true` on that tool's definition is documented to fix this by doing what?
- Automatically converting any string value Claude happens to produce into the matching integer after the fact, on the calling application's side, before the tool ever receives it
- Constraining the model's own token sampling so that its output is restricted to schema-valid completions in the first place -- so Claude's `input` field always strictly matches the declared `input_schema`, guaranteeing a correctly-typed `passengers` value rather than requiring the application to validate and retry
- Disabling the `passengers` parameter's type entirely so it can accept any value type without error, removing the mismatch by no longer checking types at all
- Requiring a human to manually review and correct every tool call's arguments before they are allowed to reach the booking function
Why B? And why not the others?
Correct answer: B. Constraining the model's own token sampling so that its output is restricted to schema-valid completions in the first place -- so Claude's `input` field always strictly matches the declared `input_schema`, guaranteeing a correctly-typed `passengers` value rather than requiring the application to validate and retry
Strict tool use works by constraining the model's own token sampling to schema-valid outputs, a technique called grammar-constrained sampling, so that Claude's generated `input` strictly follows the tool's `input_schema` from the moment it is produced -- guaranteeing a correctly-typed integer `passengers` value rather than the application having to detect a mismatch after the fact and retry. The option describing after-the-fact string-to-integer conversion on the application side is wrong because the guarantee happens during generation itself, constraining what Claude can output in the first place, not through a separate post-processing conversion step performed by the calling application. The option describing disabling the parameter's type entirely is wrong and describes the opposite effect: strict mode tightens type enforcement so the schema is always honored, it does not loosen or remove type checking. The option describing mandatory human review of every tool call's arguments is wrong because strict tool use is documented as an automated, per-request generation-time guarantee, with no human-in-the-loop step described as part of the mechanism.
Source: Anthropic, 'Strict tool use' (platform.claude.com/docs/en/agents-and-tools/tool-use/strict-tool-use) -- 'Setting strict: true on a tool definition guarantees Claude's tool inputs match your JSON Schema by constraining the model's token sampling to schema-valid outputs (a technique called grammar-constrained sampling).'