Lesson 0001 · Domains 1 & 2 · Claude Certified Architect — Foundations

How tools actually work: the agentic loop

The big picture tool_choice lives inside. Read this before Lesson 0002. ~8 minutes.

Why this lesson. Lesson 0002 drills one lever (tool_choice) in depth — this is the surrounding machine it lives in. Once you see the full request → tool_use → tool_result loop, the rest of Domains 1 & 2 (loops, MCP, errors) clicks into place — and these were exactly your "right instinct, low confidence" areas in the diagnostic.

1 · What a tool actually is

A tool is just a function you describe to Claude — three parts:

Part	What it is	Why it matters
`name`	identifier, e.g. `lookup_order`	how you reference the call
`description`	plain-English: what it does, inputs, when to use vs. similar tools	primary mechanism Claude uses to pick the right tool
`input_schema`	JSON schema of the arguments	guarantees the structure of what Claude sends

Claude never runs the tool. It only decides to call it and hands you the arguments. Your code (or an MCP server) does the actual work.

2 · The lifecycle — who sends what

Tool-use lifecycle with a weather example: our server sends Claude the question plus tool details; Claude asks the server to fetch current weather; the server runs code that calls a weather API and returns the data; Claude gives a final response using that data. — **The same loop, concretely (weather example).** ① Server → Claude: the question *plus the tool descriptions* (request). ② Claude → Server: “please fetch the weather” — that’s the `tool_use` block. ③ Server runs its own code against a weather API and returns the result (`tool_result`). ④ Claude → Server: final answer using the data (`stop_reason: "end_turn"`). Diagram: Anthropic.

1. YOU → Claude (request) tools: [...] — the function descriptions tool_choice: ... — rule: must a tool be called, and which? messages: [...] — the conversation so far 2. Claude → YOU (response) stop_reason: "tool_use" tool_use: { name, input } — Claude WANTS this call 3. YOU run the tool (your code / an MCP server) 4. YOU → Claude (next request) tool_result: { tool_use_id, content } — the output 5. Claude → YOU stop_reason: "end_turn" → final text answer …or "tool_use" again → repeat from step 3

blue = you send (input) · red = Claude sends (output)

Two pairings people mix up

tool_choice (you set, step 1) is not the partner of tool_use. It's a rule that influences step 1.
The real round-trip pair is tool_use (Claude asks, step 2) ↔ tool_result (you answer, step 4).
The loop is driven by stop_reason: "tool_use" = keep looping; "end_turn" = stop. Never stop on an iteration cap or by reading the text for "done."

3 · The three levers you control

Lever	Controls	Fix it when…
description	which tool Claude picks	it misroutes between similar tools → improve descriptions first
tool_choice	whether & which tool must be called	you need a guaranteed call → `"any"`; a specific one → forced
input_schema	the structure of the output	you need valid JSON → schema kills syntax errors (not wrong values)

4 · MCP in one breath

An MCP server is a separate process that exposes tools (and resources) over a standard protocol. The description and the implementation live on the server — not in your request.

Discovery: the host (Claude Code / your agent) connects and discovers the server's tools at connection time; they then sit in the same tool list — so tool_choice treats them like any tool.
Execution: step 3 above runs on the MCP server; the host just relays.
isError: how an MCP tool signals a failure back (instead of faking success).
tools vs resources: tools = actions; resources = read-only content catalogs (schemas, ticket lists) so the agent sees data without extra calls.
scoping: .mcp.json (project, shared, version-controlled) vs ~/.claude.json (personal); credentials via ${ENV_VARS}, never committed.

Node analogy: the MCP server ≈ a microservice with a described API; the host ≈ a client doing "service discovery" then calling endpoints. The protocol is the shared contract, so one server works with any MCP host.

Practice — does the model run hold up?

Recall, don't recognize. Pick before the feedback shows.

Primary source

📖 Read once: Anthropic's Tool use overview — the "How tool use works" section walks the exact request → tool_use → tool_result cycle. Highest-trust source for this lesson.