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

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

While Claude automatically sees 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.

Before we construct our prompt, we require the anthropic gem and initialize our API client. Then, we define the system_prompt:

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

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

Claude recognizes the available tools from the tools parameter alone. While system prompt guidance can be helpful for encouraging consistent tool usage patterns, Claude can 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 a complete tool use response by converting the response to a Hash and formatting it as JSON:

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.

Additionally, you might notice the field inside the block. This simply indicates that itself made the direct decision to invoke the tool, which is standard for autonomous tool use.

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

When you run this code, you will see the following output:

The stop_reason acts as a control flow signal for your agent. Here are the main values you will 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 its intended actions, 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 indicates how it should be handled.

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

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

Notice that we use .to_s on content_item.type in our statement. Converting them to strings with ensures a safe, robust comparison against our string literals.

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; the stop_reason field then acts as a control signal for your system.

In the upcoming practice exercises, you will work with these response structures hands-on, learning to parse tool_use requests and preparing for the next step: executing the requested tools and sending results back to Claude to complete the conversation flow.