Introducing tool use

A user asks your app: "What's the weather in San Francisco right now?" Claude reads the question, reaches for an answer, and finds nothing — because the current weather is not in the training data, and cannot be. All Claude can offer is a polite "I don't have access to real-time weather information." This is the problem tool use exists to solve.

What Claude knows, and what it doesn't

Claude's knowledge is bounded by its training data. It knows programming languages, historical facts, general reasoning patterns, and everything else that existed in the text it was trained on up to a fixed cutoff. It does not know:

• What time it is right now
• The current price of AAPL
• What's in your production database
• Whether user alice@example.com has an active subscription
• The contents of the PDF a user just uploaded
• Anything that happened yesterday

For any of that, Claude needs a way to ask your systems. Tool use is that way.

The pattern

Tool use is a structured four-step conversation between your application and Claude in which Claude requests external data and you provide it.

1. Initial request. You send Claude a user message plus a list of tools it can call, each described by a name, a description, and an input schema.
2. Tool request. Claude decides it needs one of the tools, and returns a special response block saying "call get_weather with location=San Francisco."
3. Data retrieval. Your server code reads the tool request, runs the corresponding function, and gets back the real data — by calling a weather API, querying a database, hitting an internal service, whatever.
4. Final response. You send the tool result back to Claude in a follow-up message. Claude generates a final answer using the original question plus the data you just supplied.

Notice what's happening: Claude never runs your code. It only requests that code be run. Your server does the actual execution, keeping tools, credentials, and side effects firmly on your side of the wire. This is deliberate — it's how tool use stays safe and auditable.

The weather example, concretely

Step 1 — the initial request — sends Claude:

• The user message: "What's the weather in San Francisco?"
• A tool description: "get_weather(location: string) — returns current temperature and conditions for a US city."

Step 2 — Claude responds with a tool request: "I need get_weather with location=San Francisco, CA."

Step 3 — your server sees the request, calls the actual weather API, gets back { "temp": 62, "conditions": "foggy" }.

Step 4 — you send that back to Claude as a tool result, and Claude replies to the user: "It's currently 62°F and foggy in San Francisco."

The user sees a clean, accurate, current answer. Claude sees a question-and-answer flow with a single middle step for data fetching. Your server sees a normal HTTP request to an external API. Everybody does their own job.

Why this is a big deal

Tool use turns Claude from a static knowledge base into a dynamic assistant that can:

• Access real-time information — the weather, stock prices, inventory, live telemetry.
• Integrate with external systems — your database, your CRM, your internal microservices, anyone's API.
• Ground responses in current data — instead of guessing, Claude can answer from the actual state of your world.
• Take actions — tools can also do things (create a ticket, send an email, update a row) as long as you design the function to do so.

Most non-trivial production applications built on Claude use tools. A pure prompt-only application is the exception, not the rule — because as soon as a user asks about anything that changes over time or lives in a specific system, you need a way to bring that data into the conversation.

What you'll build in this module

The rest of Module 6 walks through tool use end to end using a running example: a reminder-setting assistant. A user says "remind me about my doctor's appointment a week from Thursday," and Claude figures out the current date, adds the duration, and calls a function to actually schedule the reminder. Building that end-to-end will teach you:

• Writing tool functions in Python
• Describing them with JSON schemas
• Handling the mixed-block responses Claude returns during tool calls
• Sending tool results back in the correct format
• Running multi-turn loops where Claude may call several tools in sequence
• Working with multiple tools in one conversation
• Fine-grained control over tool behaviour
• First-party tools like the text editor and web search

By the end of the module, you'll have an assistant that takes natural language time requests and actually schedules reminders. More importantly, you'll have the full playbook for giving Claude any capability your application needs.