AniUI Academy

The Tools Claude Has

The five categories of built-in tool, what each can actually do, why the tool list is the whole difference between an agent and a chat window, and how it gets extended.

9 min read

An agent is a model plus tools plus the ability to read what those tools returned. The middle term is the one nobody looks at closely, so this lesson is the inventory.

You do not need to memorise any of it. Claude decides which tool to use; you almost never name one. But knowing roughly what exists changes what you think to ask for, and it makes the permission prompts in the next lesson legible instead of alarming.

The five categories

The built-in tools fall into five groups, each representing a different kind of agency.

CategoryWhat Claude can do
File operationsRead files, edit code, create new files, rename and reorganise
SearchFind files by pattern, search content with regular expressions, explore a codebase
ExecutionRun shell commands, start servers, run tests, use git
WebSearch the web, fetch documentation, look up error messages
Code intelligenceSee type errors and warnings after edits, jump to definitions, find references

That table is the whole product in five rows. Everything else in this course is about using it well.

What each one is actually like

Some detail, because a few of these behave in ways that explain things you will otherwise find confusing.

File operations. Reading returns the file contents with line numbers. It is not limited to text: images come back as something Claude can see rather than raw bytes, PDFs are read in page ranges, and Jupyter notebooks come back as cells with their outputs. That is why pasting a screenshot of a broken layout works.

Editing is exact string replacement. Claude supplies the text to find and the text to replace it with, and the text to find must match the file exactly and appear exactly once. Not regular expressions, not fuzzy matching. When you see Claude read a file immediately before editing it, this is why — it needs the current bytes, not an approximation of them.

Search. Two different tools with a division of labour worth knowing. One finds files by name pattern, the way **/*.tsx does. The other searches inside file contents, and is built on ripgrep, so it uses ripgrep's regular expression syntax rather than POSIX grep's.

They differ on one thing that will eventually surprise you: content search skips files ignored by .gitignore, while filename matching does not. So a search that comes back empty for a build artefact is not necessarily wrong; it may just be looking at your tracked files.

Execution. The shell. Any command you could run yourself. Two behaviours matter in practice. Each command runs in a separate process, so environment variables do not persist — an export in one command is gone by the next. And aliases and shell functions from your startup file are available, because Claude Code reads it at session start and applies them. Long-running things like dev servers can be started in the background so the session carries on while they run.

Web. Searching returns result titles and URLs; it does not fetch the pages. Fetching a page is a separate tool, and it works in a way worth understanding: the page is converted to Markdown, then a prompt describing what to extract is run against it by a small fast model, and Claude usually receives that answer rather than the page itself.

This makes fetching lossy by design. If a fetch reports that a page does not mention something, that can mean the extraction prompt did not ask about it. When it matters, asking Claude to fetch again with a more specific question is the fix.

Code intelligence. This one is off until you turn it on. With a language server available, Claude gets type errors and warnings reported automatically after each edit, and can jump to a definition, find every reference to a symbol, or trace a call hierarchy — the things your editor does. Without it, Claude is reading text and inferring structure, which works but is weaker. The language support arrives through a code intelligence plugin, which is a later lesson.

Beyond these five there are tools for orchestration rather than for touching your project: spawning a subagent that works in its own separate context window, and asking you a multiple-choice question when a decision genuinely needs your answer.

Choosing which one

Nothing in your prompt maps onto a specific tool. Claude picks, based on your words and on what it learns as it goes.

claude
  1. You typed: Users are reporting that the export button does nothing on the reports page. Have a look.

  2. Claude ran: Search: files named report*

  3. WhyFilename search first, because it is the cheapest possible way to find the neighbourhood. No file was read yet.

  4. Claude ran: Search: export in app/reports

  5. Claude ran: Read app/reports/export-button.tsx

  6. Claude replied: The handler calls exportRows, imported from lib/export. That module exists but the function is named exportRecords. The import is failing silently because the whole module is wrapped in a try/catch.

  7. WhyContent search narrowed it to one file, then a read confirmed it. Three tool calls, two categories, no edits yet.

  8. You typed: Fix it, and make the failure loud rather than silent.

  9. Claude ran: Edit app/reports/export-button.tsx

  10. Claude ran: Run: npx tsc --noEmit

  11. Output: Found 0 errors.
  12. WhyExecution as verification. Notice it reached for the type checker rather than the tests — the bug was a wrong name, and a type check is the fastest thing that has an opinion about names.

  13. Claude ran: Run: npm test reports

  14. Output: PASS  reports.test.tsx  (6 tests)
  15. Claude replied: Renamed the import and removed the surrounding try/catch so an import failure surfaces instead of being swallowed.

Search, search, read, edit, execute, execute. Nobody chose that sequence in advance.

The route is not fixed. On a different day, with a different phrasing, the same bug might be found by running the failing page first. That is the loop deciding, and it is a feature rather than an inconsistency.

The set is not fixed either

The built-in tools are the foundation, not the ceiling. Four mechanisms extend what Claude can do, and each solves a different problem.

Skills

Reusable knowledge and procedure, written as Markdown files under .claude/skills/<name>/SKILL.md. A skill teaches Claude how your team does something — how you write migrations, how you review a pull request — so you do not explain it every session. It adds instruction rather than reach.

MCP servers

Genuinely new tools, connected over an open standard. This is how Claude reaches systems it otherwise knows nothing about: an issue tracker, a design document store, an internal service, your own custom tooling. This is the one that adds reach.

Hooks

Your own shell commands, run automatically around Claude Code's actions. Format after every edit, run a linter before a commit, refuse an edit to a protected file. Deterministic rather than requested — a hook runs whether or not Claude thought of it.

Subagents

Work handed to a separate agent with its own fresh context window, defined in .claude/agents/<name>.md. It does the task and returns a summary, so a large exploration does not fill your main conversation with file contents.

Each of these gets its own lesson later, and there is a lesson after those about choosing between them, because the failure mode here is reaching for the complicated mechanism when a paragraph in a file would have done.

One detail worth carrying forward: skills do not add a new tool entry. They run through an existing tool. MCP servers do add tool entries — which is why a long-running session with several servers connected has a much longer tool list than a fresh one.

Finding out what you actually have

Your exact tool set depends on your platform, your provider and your settings, so the honest answer to "what tools do I have" is that you should ask:

What tools do you have access to?

You get a conversational summary. For the exact names of tools coming from MCP servers, /mcp lists them per server.

Exact names matter for one reason, and it is the subject of the next lesson. Permission rules, hook matchers and subagent tool lists are all written against the literal tool name — the string, spelled exactly. When you allowlist something or block something, you are naming a tool from this inventory. Which is why it was worth doing the inventory first.

What to take away

Claude's built-in tools fall into five categories: file operations, search, execution, web and code intelligence, the last of which needs a plugin before it does anything. The details of a few of them explain otherwise puzzling behaviour — editing needs an exact match, so files get read first; content search respects .gitignore while filename search does not; fetching a page is summarised on the way in and so is lossy. Claude chooses tools itself, based on what each previous result told it, so the route through a task is decided as it goes. The set is extensible through skills, MCP servers, hooks and subagents, which add instruction, reach, determinism and isolation respectively.

Next: what Claude is allowed to do with all of that without asking you first, and how to set that line where you want it.

Check yourself

5 questions · pass 4/5 to unlock Permissions and Staying in Control

up to 50
  1. 1.Why are tools described as the thing that makes Claude Code agentic?

  2. 2.Which of these is NOT one of the five categories of built-in tool?

  3. 3.Claude needs to find every file that mentions a function name. Which kind of tool is that?

  4. 4.What does the web fetch tool actually give Claude?

  5. 5.You want Claude to be able to read tickets from your issue tracker. Which extension mechanism is that?

5 left to answer