[FEATURE] Support `strict: true` on tool definitions in BedrockModel

[kaghatim]

Overview

Bedrock's Converse API supports a strict field on ToolSpecification (API docs) that enables schema validation on tool names and inputs (structured output docs). This prevents the model from hallucinating tool names or generating inputs that don't match the defined schema.

Currently there's no way to enable this through the SDK because BedrockModel._format_request only forwards name, description, and inputSchema from each tool spec, and additional_request_fields/additional_args operate at the top-level request, not inside individual toolSpec objects.

Use Case

Tool name hallucination in production — the model occasionally generates garbled tool names (e.g. store-case-syummary-tool instead of store-case-summary-tool). The agent self-corrects on the next cycle, but it wastes a cycle and extra tokens. The strict: true flag eliminates this class of error entirely.

---

Implementation Requirements

Based on clarification discussion and repository analysis:

Approach

Add a strict_tools config option to BedrockConfig that applies strict: true to all tool specs in the request. This is a model-level blanket toggle — per-tool granularity is tracked separately in #1642 / PR #1862.

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-6",
    strict_tools=True,
)

Files to Modify

1. src/strands/models/bedrock.py

   • Add strict_tools: bool | None to BedrockConfig TypedDict with appropriate docstring
   • Update _format_request to inject "strict": True into each toolSpec dict when strict_tools is enabled:

     "toolSpec": {
         "name": tool_spec["name"],
         "description": tool_spec["description"],
         "inputSchema": tool_spec["inputSchema"],
         **({"strict": True} if self.config.get("strict_tools") else {}),
     }

   • Add a warning log when strict_tools=True is used alongside citations configuration (Bedrock docs state structured outputs is incompatible with citations for Anthropic models)

2. tests/strands/models/test_bedrock.py

   • Test that strict_tools=True injects "strict": True into each toolSpec in the formatted request
   • Test that default behavior (no strict_tools or strict_tools=None) does NOT include strict in tool specs
   • Test that strict_tools=False does NOT include strict in tool specs
   • Test the citations incompatibility warning is emitted when appropriate

What NOT to change

• Do NOT modify ToolSpec TypedDict in src/strands/types/tools.py — per-tool strict field is handled by [FEATURE] Support strict tool use #1642 / PR feat(tools): support for strict tool execution #1862
• No GitHub workflow changes needed
• No changes to other model providers — this is Bedrock-specific

Interaction with PR #1862

If PR #1862 (per-tool strict on ToolSpec) lands before or after this feature:

• strict_tools on BedrockConfig acts as a model-level default
• Per-tool strict on individual ToolSpec entries could override the model-level setting in a future follow-up
• For this PR, only the model-level strict_tools config needs to be implemented

Important Bedrock Behavior Notes

• First-time schema compilation for a new schema may take up to a few minutes
• Subsequently, cached grammars are used (24-hour TTL)
• Structured outputs is incompatible with citations for Anthropic models

Acceptance Criteria

• BedrockConfig accepts strict_tools as an optional boolean parameter
• When strict_tools=True, all toolSpec objects in the formatted request include "strict": true
• When strict_tools is not set, None, or False, tool specs do NOT include a strict field
• A warning is logged when strict_tools=True is used alongside citations configuration
• Unit tests cover all scenarios (enabled, disabled, default, citations warning)
• Existing tests continue to pass
• Code follows repository conventions (type annotations, Google-style docstrings, structured logging)

[zastrowm]

/strands refine

[github-actions]

Repository Analysis & Clarifying Questions

I've analyzed the repository and the Bedrock API documentation. The feature request is well-defined — here's what I found and a few questions before finalizing the implementation spec.

Repository Context

• BedrockModel._format_request (line ~257-266 in src/strands/models/bedrock.py): Currently only forwards name, description, and inputSchema for each tool spec. This is intentional because Bedrock strictly validates content blocks and rejects unknown fields.
• ToolSpec TypedDict (src/strands/types/tools.py): Shared across all model providers. Currently has description, inputSchema, name, and outputSchema (NotRequired).
• BedrockConfig: Uses TypedDict pattern with many optional config fields (guardrails, caching, service tier, etc.). Adding strict_tools here follows the established pattern.
• Bedrock API docs confirm: strict is an optional boolean on ToolSpecification — "Flag to enable structured output enforcement on tool usage response."

Clarifying Questions

1. Model-level config vs. per-tool ToolSpec field

The proposed solution adds strict_tools to BedrockConfig, which applies strict: true to all tools uniformly. An alternative (mentioned in the issue) would be to add a strict field to the shared ToolSpec TypedDict so each tool can opt in individually.

Should the implementation:

• (a) Only add strict_tools to BedrockConfig (model-level, all-or-nothing) — as proposed?
• (b) Also add strict as a NotRequired field on the ToolSpec TypedDict for per-tool granularity?
• (c) Only add to ToolSpec (per-tool), no model-level config?

Option (a) is simplest and matches the author's proposal. Option (b) would future-proof for users who want strict on some tools but not others, though the _format_request would need to check both the per-tool field and the model-level config.

2. Citations incompatibility warning

The Bedrock docs state that "Structured outputs is incompatible with citations for Anthropic models." Should the SDK emit a warning when strict_tools=True is used alongside citations configuration, or is that out of scope for this change?

3. No GitHub workflow changes needed

Based on my analysis, this feature requires no changes to CI/CD workflows. Just confirming this is expected.

Implementation Summary

Based on the proposed solution, the changes would be:

• src/strands/models/bedrock.py: Add strict_tools: bool | None to BedrockConfig; update _format_request to inject "strict": True into each toolSpec when enabled.
• src/strands/types/tools.py: Optionally add strict: NotRequired[bool] to ToolSpec (depending on answer to Q1).
• tests/strands/models/test_bedrock.py: Add unit tests for the new config option covering: default behavior (no strict), strict_tools=True, and the formatted request structure.

This is a small, well-scoped change (~3-4 files) suitable for a single PR.

[kaghatim]

Q1: I'd go with (a), just strict_tools on BedrockConfig. The per-tool ToolSpec approach is already being tracked in #1642 with an open PR (#1862). I think these are complementary. strict_tools would be a model-level blanket toggle
for when you want strict on everything without annotating each tool individually. If #1862 lands first, strict_tools could act as a default that individual tool specs can override.

Q2: I think a warning log when strict_tools=True is used alongside citations config would be reasonable.

[zastrowm]

/strands

Q1: I'd go with (a), just strict_tools on BedrockConfig. The per-tool ToolSpec approach is already being tracked in #1642 with an open PR (#1862). I think these are complementary. strict_tools would be a model-level blanket toggle for when you want strict on everything without annotating each tool individually. If #1862 lands first, strict_tools could act as a default that individual tool specs can override.

Q2: I think a warning log when strict_tools=True is used alongside citations config would be reasonable.

Agree with ^; update reqs

[zastrowm]

/strands implement

[zastrowm]

@kaghatim strands will give you a basis that you can jump off if you want

[kaghatim]

perfect! Thanks @zastrowm! Appreciate the quick help and support here.

[github-actions]

Unable to create pull request via API. You can create it manually by clicking here.