Programmatic tool calling and allowed_callers

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. You have programmatic tool calling working on Claude Sonnet 5 (claude-sonnet-5) and now want the same custom tool to also carry a hard schema-conformance guarantee, so a compliance reviewer asks whether strict: true can simply be added to that tool definition. How should you evaluate this proposal?

   Right. In the game that’s Renown for your Tool Design, MCP and Server Tools building.

   Not that one: D is right. In the game your Tool Design, MCP and Server Tools building would lose a little Renown, and this question would come back later.

   Your answerA.Strict tool use and programmatic tool calling combine freely, since one validates input and the other routes calls.The two features are documented as mutually exclusive. Programmatic tool calling lists strict tool use among its incompatibilities, alongside forced tool_choice, disable_parallel_tool_use and MCP tools.Your answerB.Strict tool use applies only when the tool is called from the sandbox, and is ignored on direct calls.There is no path-dependent downgrade in which strict mode quietly applies to some calls and not others. The incompatibility is a property of the configuration.Your answerC.Strict tool use requires the code-execution-2025-08-25 beta header when programmatic tool calling is enabled.Attributes the restriction to a missing beta header, but programmatic tool calling needs no beta header and no header re-enables strict mode with it.The answerD.Strict tool use is incompatible with programmatic tool calling, so the guarantee needs client-side validation.Programmatic tool calling is not compatible with strict: true, forced tool_choice, disable_parallel_tool_use, or MCP tools.

   Show the full explanation and doc quotes

   When the sandbox is orchestrating calls, schema conformance has to be enforced by validating in the tool implementation and returning tool_result with is_error: true on a violation.

   Written from platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling

2. Your service uses programmatic tool calling on Claude Opus 5 (claude-opus-5). Claude's code calls query_database, and the API returns a tool_use block whose caller names the code execution run. Your client answers with a tool_result in a request rebuilt from the stored message history alone, and the API rejects it. What is the most likely cause?

   Right. In the game that’s Renown for your Tool Design, MCP and Server Tools building.

   Not that one: C is right. In the game your Tool Design, MCP and Server Tools building would lose a little Renown, and this question would come back later.

   Your answerA.The tool_result must carry the caller object copied from the tool_use block.caller is a response field on the tool_use block that identifies the code execution run. A tool_result carries tool_use_id and content, not caller.Your answerB.The tool_result must be sent with disable_parallel_tool_use inside tool_choice.disable_parallel_tool_use: true is not supported with programmatic tool calling at all, so it cannot be part of the resumption contract.The answerC.The request omits the container id, which is required while a call is pending.Programmatic tool calling runs inside a code execution container that is paused waiting for the result. While a programmatic call is pending, the container id is required rather than optional on the request, and the API rejects a request that omits it.Your answerD.The request omits the strict flag that programmatic tools require on resumption.Tools with strict: true cannot be enabled for programmatic calling, so no strict flag is involved in resuming a paused call.

   Written from platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling

3. Your Claude Opus 5 (claude-opus-5) service enables programmatic tool calling over a warehouse query tool. Some queries take six to eight minutes. Those runs come back with TimeoutError: Calling tool ['run_query'] timed out in stderr, a return_code of 0, and Claude retrying the same call. What change would most effectively resolve the issue?

   Right. In the game that’s Renown for your Tool Design, MCP and Server Tools building.

   Not that one: C is right. In the game your Tool Design, MCP and Server Tools building would lose a little Renown, and this question would come back later.

   Your answerA.Raise the request's top-level max_tokens so the container stays open longer.max_tokens bounds generated output. It has no effect on how long a paused programmatic call waits for a tool result.Your answerB.Reuse the container by passing its id, which extends the pending-call window.Passing the container id is already mandatory while a call is pending. It preserves state and does not lengthen the four-minute window.The answerC.Split each query into chunks that return well inside the four-minute call timeout.A programmatic tool call that has not received its result within roughly four minutes raises a TimeoutError inside Claude's running code, which Claude sees in stderr and typically retries.Your answerD.Set max_uses on the code execution tool so fewer calls compete for the container.The code execution tool definition accepts only a fixed type and the name code_execution. There is no max_uses field on it.

   Show the full explanation and doc quotes

   The documented remedy is to break long operations into smaller chunks that return well before that limit.

   Written from platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling