Welcome to understanding how Claude responds when it decides to use your tools! In the previous lesson, you learned how to create tool schemas that describe your functions to Claude. Now you'll discover how to include these tools in your API requests and, more importantly, how to interpret Claude's responses when it wants to use them.

In this lesson, you'll learn how to configure your requests to enable tool use, understand the different types of responses Claude can provide, and extract the specific information you need to execute the tools Claude requests. By the end, you'll be able to recognize when Claude wants to use a tool and gather all the details needed to make that happen.

While Claude will automatically see and can use any tools you provide in your request, mentioning tools in your system prompt can help ensure more consistent behavior and guide Claude toward using them appropriately.

Here's an example of how you can improve your system prompt:

This guidance helps Claude understand your preferences for when and how to use tools, but it's not required for tool functionality. Claude can still recognize and use tools based solely on their availability in the request.

The tools parameter is the essential component that makes your functions available to Claude. This parameter accepts the JSON array of schemas you created in the previous lesson:

Claude will recognize the available tools from the tools parameter alone. The system prompt guidance can be helpful for encouraging consistent tool usage patterns, but Claude will still be able to see and use your tools even without explicit instructions in the system prompt.

When Claude decides to use a tool, the response structure changes significantly from a simple text response. Let's examine what a complete tool use response looks like by printing the entire response structure:

This will output a detailed JSON structure showing all the components of Claude's response:

Notice two key differences from regular text responses:

• The stop_reason is "tool_use" instead of "end_turn"
• The content array contains both text and tool use blocks

This structure allows Claude to explain what it's doing while providing the structured information your system needs to execute the requested functions.

The stop_reason field is your primary indicator for determining what action to take next in your agent logic. Let's extract and examine this field to understand its possible values:

When you run this code, you'll see the following output:

The stop_reason acts as a control flow signal for your agent. Here are the main values you'll encounter:

• "tool_use": Claude has requested tool execution and is waiting for results
• "end_turn": Claude has completed its response and the conversation can continue normally
• "max_tokens": Claude reached the token limit and may have more to say
• "stop_sequence": Claude encountered a predefined stop sequence

Understanding these values helps you build proper agent logic that responds appropriately to Claude's intentions.

When stop_reason is "tool_use", the content array contains a mix of text explanations and tool use requests. Claude includes text blocks to explain its reasoning and what it's about to do, making the interaction more transparent and user-friendly. The content array can also contain multiple tool use blocks when Claude wants to execute several tools in parallel. Each content item has a type field that tells you how to handle it.

Let's iterate through the content array to examine each item:

Running this code will show you the structure of each content item:

Each tool use block contains three essential pieces of information that your system needs to execute the requested function:

• name: The function name that matches your tool schema (e.g., "sum_numbers")
• input: A dictionary of parameters to pass to your function, with keys matching your schema's parameter names
• id: A unique identifier for this specific tool use request, which you'll need when sending results back to Claude

You now understand how Claude communicates its tool use intentions through structured API responses. When Claude decides to use tools, it provides both human-readable explanations and machine-readable tool use blocks within the content array, with the stop_reason field acting as a control signal for your system.

In the upcoming practice exercises, you'll work with these response structures hands-on, learning to parse tool use requests and prepare for the next step: actually executing the requested tools and sending results back to Claude to complete the conversation flow.