Your First Tool-Using Loop — Tool Use, Function Calling & MCP

Every lesson so far in this course has described tool use from the outside: what a tool declaration looks like, what a `tool_use` block contains, what a `tool_result` is supposed to reply with. None of that description tells you what actually breaks when you wire it up yourself for the first time — the ordering bug that silently corrupts a conversation, the id that almost matches but doesn't, the loop that never terminates because nothing told it when to stop. This lesson is where you build the thing rather than read about it.

By the end you will have written two real tools with genuine input schemas, a dispatcher that validates arguments and never lets an exception escape unhandled, and an agent loop that runs while `stop_reason` is `"tool_use"`, appends messages in the order the API requires, and gives up cleanly after a fixed number of turns instead of spinning forever. The final run answers a question that genuinely needs two different tools called one after another, and prints the full message trace so you can see the conversation grow turn by turn.

Every code block in this lesson runs without an API key. A small `FakeClient` class returns scripted responses shaped exactly like the real `anthropic` SDK's `client.messages.create(...)` output — same `.content` list of blocks, same `.stop_reason` string — so the loop logic you write against it is identical to the loop logic you would run against `anthropic.Anthropic()`. The swap from fake to real is a single line, marked clearly where it happens, and nothing else in the loop changes. That is not a simplification for teaching purposes; it is the actual point of building the fake client this way.

Analogy🏏Cricket

🏏 Think of it like cricket: MS Dhoni, keeping wicket during a tense IPL chase at Chepauk, watches a ball rap the batter's pad and hears a loud appeal. He does not personally have Hawk-Eye vision. Instead, he raises his gloves for a review, and the on-field umpire radios the third umpire, who pulls up ball-tracking, checks the point of impact, and reports back a precise verdict: "umpire's call, clipping leg." Only after that report lands does Dhoni's team decide the next action — review sustained, lost, or the bowler simply runs in for the next delivery. Nothing about the over pauses arbitrarily; the game stops exactly long enough for one specific question to be answered by a specialist system, then resumes with that answer folded into the decision. A tool-using loop works the same way. The model does not have live data sitting in its head — it recognizes when a question needs an external check, requests exactly that check, waits for the verdict to come back, and only then decides whether to ask another question or give its final answer. Just as a captain cannot review indefinitely — the review system itself caps how many can be requested — a well-built loop caps how many rounds of asking it will allow, so a confused model consulting tool after tool cannot stall the equivalent of the whole match.