Project overview

A user types: "Set a reminder for my doctor's appointment. It's a week from Thursday." You want Claude to respond: "OK, I will remind you." — and have an actual reminder actually scheduled when it does. This sounds like a one-paragraph feature. It isn't. Building it properly requires teaching Claude three things it does not natively know how to do, which is exactly why this project is a good place to learn the whole tool use workflow.

What Claude is bad at, specifically

Three concrete gaps sit between "user intent" and "scheduled reminder":

1. Time precision. Claude may know roughly what year and month it is, but it does not know the exact current date and time when your application is running. That precision has to come from somewhere — your server has a clock; Claude doesn't.

2. Date arithmetic. Claude isn't fully reliable at date math, especially for phrases like "a week from Thursday" or "in 43 days." It sometimes gets the right answer, sometimes off-by-one, sometimes off-by-several. For anything scheduling-related, sometimes is not good enough.

3. Actually setting a reminder. Claude has no built-in way to schedule anything. Scheduling is an action that has to touch a real system — a database row, a queue message, a cron entry, a calendar API.

Each of these gaps is a tool waiting to be built. That's the core insight of this module: when Claude has a limitation, you don't try to fix it with a better prompt. You bridge the gap with a tool that's good at precisely the thing Claude is bad at.

Three tools, one per gap

The project uses exactly three tools, mapped one-to-one to the three limitations:

• get_current_datetime — returns the exact current date and time from the server's clock. Fixes time precision.
• add_duration_to_datetime — takes a datetime and a duration (days, weeks, hours) and returns the resulting datetime. Fixes date arithmetic with deterministic Python timedelta logic.
• set_reminder — records a reminder in a store (in the course, a simple dict; in production, your database). Fixes the "no mechanism to schedule anything" gap.

Chained together, they handle the user's request end-to-end. Claude receives the "a week from Thursday" phrase, calls get_current_datetime to anchor itself in time, calls add_duration_to_datetime to compute the target date, and finally calls set_reminder to actually schedule it. One sentence from the user, three tool calls under the hood, one clean natural-language response back.

Build them one at a time

The module builds these tools sequentially, not all at once. Here's the sequence and why it matters:

• Tool 1: get_current_datetime — the simplest possible tool. One function, one schema, one parameter. You'll use it to learn the full tool-calling round-trip: writing the function, writing the schema, handling the multi-block response Claude returns, sending the result back, and seeing the final answer. Everything you learn here transfers directly to the next two.
• Tool 2: add_duration_to_datetime — slightly more complex, with multiple parameters and unit handling. This is where you'll start writing schemas with real type constraints.
• Tool 3: set_reminder — a side-effecting tool that actually changes state on your server. By the time you get here, the tool-calling mechanics are familiar, so the focus is on designing tools that do things rather than just return data.

By the end you'll have a small working assistant and, more importantly, the muscle memory for every part of the tool use pattern — writing tool functions, generating and validating schemas, handling the request/response cycle, running multi-turn loops where Claude chains multiple tool calls in one conversation, and managing tool results cleanly.

The principle to carry with you

When Claude has a limitation, extend capability through tools rather than fighting it with prompt tricks. You could try to write a prompt so precise that Claude calculates "a week from Thursday" correctly every time. That prompt would be brittle, long, and still occasionally wrong. Or you could write eight lines of Python that add a timedelta and a schema that tells Claude when to use it. The second approach is shorter, more reliable, and more debuggable.

Every production application built on Claude eventually hits limitations — time, data freshness, access to specific systems, deterministic calculations, side effects. The pattern for dealing with every one of them is the same: build a tool. The next lesson starts with the simplest one.