Running tool functions

🤖 Tool Use and Execution Workflow

**I. Handling Tool Use Requests**

• Identification: When receiving a response from the LLM (e. g. , Claude), identify all "tool use parts. "
• Parallel Execution: Code must be defensive, assuming the LLM may request multiple tools to run simultaneously.
• run_tools Function: This function processes the list of parts:
• It iterates through the parts and uses a comprehension to extract only the tool use requests (parts containing the tool_use key).
• For each request, it extracts three critical pieces of information:
• tool_use_id (Unique identifier for the request).
• name (The name of the tool/function to run).
• input (The arguments/parameters for the tool).

**II. Executing the Tool**

• run_tool Function: This helper function executes the actual code.
• It accepts the name and the arguments (input).
• It uses conditional logic (e. g. , if/else) to map the tool name to the corresponding function.
• Argument Handling: The input dictionary must be "splatted" (**tool_input) into the function call.
• Error Handling: The function must include a check to handle cases where the requested tool name does not exist or is misspelled, raising an exception.

**III. Generating Tool Results (The Feedback Loop)**

• Purpose: After a tool runs, its output must be sent back to the LLM as a "tool result part" to inform its next action.
• Tool Result Part Structure: This dictionary contains:
• tool_use_id: Crucial for linking the result back to the original request, especially when multiple tools run in parallel.
• content: The output from the tool (must be serialized as a string).
• status: A flag indicating either "success" or "error. "
• Robust Implementation: The process of generating the result part should be wrapped in a try... except block.
• If the tool execution fails, the status must be set to "error," and the error message must be included in

Takeaways

• Tool use workflows require identifying and extracting the tool_use_id, name, and input from LLM responses, assuming multiple tools may run in parallel.
• Tool execution maps the requested name to a specific function, using splatting to pass the input arguments and including checks for misspelled or non-existent tools.
• Tool results must be sent back to the LLM as a "tool result part," which includes the original tool_use_id to link the output to the request.
• The result part must contain the tool's content (serialized string) and a status flag indicating either "success" or "error. "
• Robust implementation requires wrapping tool execution in a try... except block to ensure the status is correctly set to "error" if the tool fails.