Sonnet 5.5 on Bedrock has no strict tools: check Sume calls first

Anthropic says strict tool use is unavailable for Claude Sonnet 5.5 on Amazon Bedrock. Validate arguments yourself and use Sume dry_run before paid calls.

5 min readSume
All posts

If you run Claude Sonnet 5.5 on Amazon Bedrock, Anthropic's migration guide says structured outputs, which include strict tool use, are not available there. You send tool_choice: auto without strict, say in the prompt when to call the tool, and validate the tool input in your own code. For Sume tools that means a schema check in your handler plus a dry_run=true call before any paid submit.

What the guide says

The Sonnet 5.5 migration guide first removes forced tool choice: any and tool return a 400. It then points to strict tool use as the replacement, and adds that on Amazon Bedrock the strict feature is not offered for this model. The strict tool use page describes the guarantee you lose: with strict: true the input follows the schema, without it you can get a string where you wanted an integer.

I could not confirm from Anthropic's pages whether that Bedrock gap is permanent, so check the migration guide again before you design around it.

A two-step check for Sume tools

Sume's hosted MCP does not depend on Claude's strict mode, so the useful move is to validate twice: once on your side, once on Sume's. The MCP tools and gates page lists the gates a paid call carries.

Checks to put in front of a paid call (read 2026-10-04)
CheckWhere it runsWhat it catches
Your own schema validationYour handlerWrong types, missing fields, extra keys
tools_schema for the toolSume MCPA stale argument shape in your prompt
dry_run=trueSume MCPAdmission and cost preview without submitting
idempotency_keySume MCPA retried call paying twice

A prompt line that replaces strict mode

Since the model may skip the tool or fill it loosely, spell the rule out in the system prompt:

  • Call tools_schema for a tool the first time you use it in a session.
  • For any paid tool, call it first with dry_run=true, show the estimate, and wait for a yes.
  • Always send a fresh idempotency_key per intended submission, and reuse it only for an exact retry.
  • Pass max_spend_usd when the user named a budget.

What dry_run does and does not do

The docs describe dry_run=true as an admission and cost preview that does not submit the job, and max_spend_usd as enforced only when you provide it. The generation admission page explains why a valid submit can still end up queued, and what 402 insufficient_credits and 429 queue_full mean. A dry run is a preview of the moment you ask, not a reservation, so balance can change before the real call.

Validate in code anyway. A dry run tells you the call would be admitted; it does not tell you the model chose the right clip length. Your handler should reject a duration or count outside the range your product allows before Sume ever sees it.

If you can leave Bedrock

On the first-party API with strict tool use available, the schema guarantee comes back, and the capped Agent Completion tool shows the pattern. Sume itself works the same from either host, because the call is an HTTPS request from your handler or MCP client.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume