fix: correct Bedrock tool call argument extraction field name

[alvinttang]

Summary

Fixes #4748

• Bug: In crew_agent_executor.py line 850, func_info.get("arguments", "{}") returns the truthy string "{}" when the key is absent, preventing the or operator from ever falling through to Bedrock's input field. This causes all AWS Bedrock tool calls to receive empty arguments {}.
• Fix: Use func_info.get("arguments") (returning None when absent) so the or correctly falls through to tool_call.get("input"). This matches the already-correct pattern in agent_utils.py line 1157.

Change

- func_args = func_info.get("arguments", "{}") or tool_call.get("input", {})
+ func_args = func_info.get("arguments") or tool_call.get("input") or {}

Why this works

• When tool_call is an OpenAI-format dict with function.arguments, func_info.get("arguments") returns the arguments (truthy), so it is used directly.
• When tool_call is a Bedrock-format dict with input, func_info.get("arguments") returns None (falsy), so the or falls through to tool_call.get("input") which returns the Bedrock arguments.
• The trailing or {} provides a safe empty-dict default if neither field is present.

Test plan

• Verify existing OpenAI-format tool calls still work (arguments extracted from function.arguments)
• Verify Bedrock-format tool calls now correctly extract arguments from input field
• Run existing test suite: pytest lib/crewai/tests/agents/test_native_tool_calling.py

---

Note

Low Risk
Low risk, one-line change in native tool-call parsing to fix argument extraction for Bedrock-formatted tool calls; limited to how tool call payloads are interpreted.

Overview
Fixes native tool-call argument extraction in CrewAgentExecutor._parse_native_tool_call by removing the default "{}" fallback for function.arguments, allowing the logic to correctly fall through to Bedrock’s input field (and finally {}) when arguments is missing.

^{Written by Cursor Bugbot for commit 1348672. This will update automatically on new commits. Configure here.}

[alvinttang]

Review

This is a one-line fix changing func_info.get("arguments", "{}") or tool_call.get("input", {}) to func_info.get("arguments") or tool_call.get("input") or {}.

Analysis:

1. The bug: With the old code, if func_info["arguments"] is "" (empty string) or None, the get("arguments", "{}") returns that falsy value, then or falls through to tool_call.get("input", {}). But crucially, if func_info has "arguments": "" the get returns "" which is falsy, so it falls through correctly. The real issue is likely with Bedrock's response format — looking at the field name in the title: "correct Bedrock tool call argument extraction field name".

   Actually, re-reading: the old default "{}" (a string) vs {} (a dict) is the real problem. If func_info has no "arguments" key AND tool_call has no "input" key, the old code returns "{}" (a JSON string), not {} (a dict). Downstream code that tries to do func_args.get(...) or iterate over func_args as a dict would crash on the string "{}".

2. The fix: By removing the defaults from get() and using a chained or {}, the fallback is always a proper dict {}. This is correct.

3. However — missing json.loads: If func_info.get("arguments") returns a JSON string (which is common — many LLM APIs return tool arguments as a JSON string, not a parsed dict), then func_args will be a string. The code downstream presumably needs a dict. Is there a json.loads call somewhere downstream, or does this function's caller handle string-to-dict conversion? If not, this fix solves one case (missing arguments) but may still fail when arguments are present as a string. Worth verifying the downstream handling.

4. No test: A test case with Bedrock-style tool call responses (both with and without arguments) would help.

The fix is directionally correct. Small concern about whether string arguments are handled downstream.