Lesson 28.1 gave you the formula: model plus instructions plus tools plus state plus loop. The model proposes; the instructions define the job. But neither one can touch the outside world. Reading a filing, checking a price, saving a draft — all of that happens through tools.

From Part V to here

Class 13 taught you that an API is a counter where one program sends a structured request and gets structured data back. Class 15 taught you that MCP standardizes how an agent discovers and calls those capabilities: ask what is offered, send named inputs, receive structured results.

This lesson is the other side of that connection. MCP and APIs describe how tools are *exposed*. Now you decide which tools one specific agent is *allowed to select and sequence* — and in what order it may use them.

An agent never touches files or networks directly. It asks. The tool runs. That separation is what makes permissions inspectable: every outside effect passes through a named tool with a defined shape.

Three kinds of hands

Sort every candidate tool into one of three buckets before you grant it:

The buckets matter because they carry different failure costs. A broken read tool wastes time. A broken write tool litters your workspace. A broken consequential tool sends money, publishes claims, or deletes work — and no apology drafts it back.

Every tool, in any bucket, has four things you must be able to state:

1. Input schema. Which named fields does it take? ("Company name and year" — not "does research.") 2. Output. What structured result comes back, and where does it go? 3. Failure mode. What happens when the source is down, the fields are wrong, or the result is empty? 4. Permission scope. Which accounts, folders, or services can it reach — and which are off limits?

If you cannot answer all four, you are not ready to grant the tool.

Worked example: the stock-research agent

Give the example a concrete boundary. A v1 stock-research agent is allowed to:

• Read: retrieve company filings by ticker and year; fetch daily price history for named symbols.
• Write: save a draft report to a drafts/ folder with citations and a confidence note.
• Never without approval: publish the report, send it to anyone, place a trade, or write to a production database.

Walk one run:

receive tickers + question → load prior state
  → call read tool: retrieve filings (AAPL, 10-K, 2025)
  → call read tool: fetch prices (AAPL, last 90 days)
  → model drafts summary, each claim linked to a filing page or price row
  → call write tool: save drafts/2026-09-12-AAPL-notes.md
  → stop. Report waits for human review.

Notice the shape of the evidence. The draft is not "the model remembers Apple did well." It is a sentence tied to a retrieved filing paragraph, plus a price table tied to a fetched row. A tool response is evidence; a model's memory is not. Lesson 30.4 will make this a scoring rule, but the habit starts here: every claim points at a tool result.

Now imagine the failure version. The filings source is down. The agent must not invent numbers to fill the gap. Its instructions say: record the tool error in state, mark the affected claims as missing evidence, and stop with a clear note — "filings unavailable, prices only." Failure handling is part of the tool design, not an afterthought.

The smallest-tool principle

Start with one safe read tool and one clear output. Add nothing else until that pair works end to end.

For the research monitor from Lesson 28.1, that means: one fetch_page tool pointed at approved sources, plus one write_review_packet tool pointed at a review folder. No browser automation, no shell, no database writes, no deployment access. Each of those adds permissions, cost, fragility, and audit burden — earn them one at a time.

The test is simple. Before adding a second tool, demonstrate: the agent called the first tool, handled one failure (a missing page, an empty result), saved one output in the right place, and stopped. If that loop is not inspectable, more tools only multiply the fog.

Check your understanding

1. Sort these into read, write, or consequential: fetch a filing, save a draft, publish a post, place a trade, append to a review queue. 2. Name the four things you must state for every tool. 3. Why is a tool response evidence while a model's memory is not? 4. What breaks when you grant five tools before the first one works?

Exercise: make a tool inventory

For the agent on your AGENT-CARD.md, list every tool you are tempted to grant. Sort each into one of four columns:

Be specific about scope: "read filings for named tickers via the approved API" beats "access financial data." "Write drafts to drafts/ only" beats "write files."

Finish line: a one-page inventory with at least one tool in each column and a one-sentence scope for every row.

Verify: for each row, check you can state its inputs, its output location, its failure behavior, and its scope. Any row you cannot specify goes to "needs approval" or "never" until you can.

Common failure: a read tool with an unlimited scope ("browse the web," "read all files"). Narrow it to named sources or folders. If the agent needs a new source later, that is a deliberate grant — not a silent expansion.

Next, you give the agent continuity: state that survives after the chat window closes.