Claude Code Guide — Part 6: The built-in tool inventory

Why know the inventory

Parts 1 through 5 authored on-disk surfaces — the brief, the audited settings, the Skills, the subagents, the hooks. This part is different. It catalogues what was already there: the built-in tools the Claude Code CLI ships with. The model reaches for these on every meaningful turn. Knowing the inventory is how you make sense of the lines that appear in your session ("Reading file at lib/foo.ts", "Running command pnpm test"), how you scope your .claude/settings.json permissions accurately, and how you decide which step of a four-phase workflow each tool serves.

This is a reference, not a tutorial. Each entry is one paragraph plus one example of how the tool surfaces in the transcript. For anything beyond what is here, the canonical reference is at docs.claude.com/en/docs/claude-code/ — every tool below has a deeper section in the official docs and a permission syntax page worth reading once.

A note on scope: every tool in this inventory ships with Claude Code. Plugins (the cAgents plugin's slash commands, third-party MCP servers, custom commands you author yourself) are not in this list. The Skill entry below covers the dispatch mechanism the CLI uses to run any installed Skill — that mechanism is built in. The Skills it dispatches to may be your own files from Part 3 or shipped bundles. Either way, the tool firing the dispatch is the one in this catalogue.

File tools

Read

Reads a file from disk and returns its contents. The model reaches for it whenever it needs to see what a file actually says — before making an edit, while answering a question about how the codebase is shaped, or when validating that a write landed. Permission implications: Read(./**) is a common project-shared allow for the project tree; Read(./.env*) and Read(./secrets/**) belong in deny (see Part 2). Reference: docs.claude.com/en/docs/claude-code/.

When it surfaces: a session line like "Reading file at lib/markdown.ts" — that is the Read tool firing. The output the model sees is the file contents (or an error). Lines outside the project root are usually a sign of a too-broad allow.

Write

Creates a new file or overwrites an existing one with new contents. The model reaches for it when authoring a fresh file (a new test, a new article, a generated config) and sometimes when a full rewrite is cheaper than a sequence of edits. Permission implications: scope Write(./**) to your project tree; deny writes to credentials, secrets, and any path you do not want overwritten. The tool overwrites, so a single misfire can cost you a file.

When it surfaces: "Writing file at app/page.tsx" — Write firing. The session shows the path; the diff is what landed.

Edit

Performs exact string replacements in an existing file. The model reaches for Edit instead of Write when modifying a known file, because Edit only sends the diff and is far harder to misuse. The string match must be unique unless replace_all is set. Permission implications: same scope as Write; in practice if you allow Edit(./**) you allow Write(./**) because they reach the same files.

When it surfaces: "Editing file at lib/markdown.ts" — Edit firing. The session shows the old/new strings or the file path; if the match was not unique the tool errors and the model retries with more context.

Glob

Finds files by name pattern. Fast directory traversal, returns a sorted list of paths matching the pattern. The model reaches for it when looking for files of a specific shape (**/*.test.ts, **/components/*.tsx) before reading any of them. Permission implications: usually no narrower control than file Reads — if Read(./**) is allowed, Glob over the same tree is too.

When it surfaces: "Searching for files matching **/*.md" — Glob firing. The output is a list of paths; the model picks which to Read next.

Grep

Searches file contents with a regex. Powered by ripgrep under the hood — fast on large trees. The model reaches for it when the question is "where is this defined / used / referenced?" and a Glob alone will not answer it. Permission implications: like Glob, scoped by the same Read permissions; output never leaves the search context.

When it surfaces: "Searching for processCalloutsInHtml in lib/" — Grep firing. The output is matching lines with file paths and line numbers.

Shell

Bash

Executes a shell command and returns stdout, stderr, and exit code. The model reaches for it constantly — running tests, running the build, running the linter, listing files, checking git status. This is the tool whose permissions you will calibrate the most in .claude/settings.json. Permission implications: never Bash(*); always specific commands or narrow :* suffixes (see Part 2). Hooks (Part 5) are the deterministic enforcement layer for the patterns you cannot trust to permission entries alone.

When it surfaces: "Running command pnpm test" — Bash firing. The output is the command output (stdout/stderr) and exit code. Long-running commands can be backgrounded; the tool surfaces the same way either way.

Task tracking

TodoWrite

Manages a structured task list scoped to the current session. The model reaches for it whenever a task has three or more distinct steps, and it surfaces the list in the session UI as an evolving checklist. The list survives compaction and is the persistence surface that lets a long session remember what it was doing across context resets. TodoWrite is the planning surface the four-phase method (Part 7) anchors on — the Plan phase writes the list, every later phase reads it. Permission implications: TodoWrite has no permission gating; it is structured prose, not a side-effecting tool.

When it surfaces: a checklist appears in the session UI, with items marked pending / in_progress / completed. Updates are live — you watch the list move as the model works.

Interaction

AskUserQuestion

Pauses the session and asks you a structured question. The model reaches for it when a decision is genuinely yours to make — branch name conventions, scope tradeoffs, whether to keep a piece of dead code. Different from a permission prompt: a permission prompt asks "may I run this command?", AskUserQuestion asks "which option do you want?". Permission implications: none; the tool only displays a question and waits.

When it surfaces: a question prompt with options appears in your session. Useful when the model is honest about not knowing what you want; suspicious when the model uses it to defer a decision it should have inferred from CLAUDE.md.

Composition

Skill

Dispatches into an installed Skill — either one you authored under .claude/skills/<name>/SKILL.md (Part 3) or one shipped with Claude Code or installed via a plugin. The model reaches for the Skill tool when a slash command is invoked, when a reference Skill's description matches the conversation, or when another tool composes through Skill explicitly. Permission implications: the per-Skill allowed-tools floor is what governs the Skill's runtime, intersected with project settings. The Skill dispatch tool itself is not gated.

When it surfaces: "Using Skill: house-style" or a slash command runs and the model behaves differently for the rest of the turn — the Skill body landed in context.

Task

Spawns a subagent (a forked-context worker authored in .claude/agents/<name>.md — see Part 4) and waits for its report. The model reaches for Task when delegating bounded work and not wanting the intermediate transcript in the main context. Permission implications: the subagent's tools whitelist is intersected with project settings — Task itself does not bypass any of your allow/deny rules.

When it surfaces: "Spawning subagent: repo-researcher" — the controller fires Task, the subagent runs, the report returns. The main session sees only the report.

ToolSearch

Searches and loads schemas for tools that are not always present in the model's prompt — the deferred tools surfaced in some sessions. The model reaches for it when it needs a tool whose schema has not been loaded yet, typically scheduling, MCP-bridged tools, or the rare Task variant. Permission implications: ToolSearch loads schemas, not actions — the loaded tool then runs under its own permission rules.

When it surfaces: "Loading tool schema: WebFetch, WebSearch" — schemas attach mid-session and the tools become callable for the rest of the turn.

Scheduling

ScheduleWakeup

Schedules the session to resume work after a specified delay, used in dynamic-pace /loop runs and a few self-pacing patterns. The model reaches for it when the work needs to come back later — a build is compiling, a deploy is in flight, a remote condition needs to settle. Permission implications: usually none beyond the project allow for the work the wake-up resumes; the schedule itself is harness state.

When it surfaces: a wake-up notice in the session UI saying "resuming in N seconds." The session pauses; another turn fires when the timer elapses.

Web

WebFetch

Fetches the contents of a URL. The model reaches for it when it needs the actual contents of a doc page, an issue, an article — anything whose URL the user has cited or whose contents are needed verbatim. Permission implications: never bare WebFetch; always WebFetch(domain:nextjs.org) or whichever specific domain you trust. The blast radius of an open WebFetch is real; an attacker-controlled URL could exfiltrate context or pull in poisoned instructions.

When it surfaces: "Fetching https://nextjs.org/docs/app" — WebFetch firing. The page contents land in context for the rest of the turn.

WebSearch

Issues a web search query and returns ranked results. The model reaches for it when it needs to discover URLs rather than fetch one it already knows. Permission implications: usually allowed wholesale; the results are URLs and snippets, not arbitrary code.

When it surfaces: "Searching the web for Next.js 16 App Router static export" — WebSearch firing. The output is a list of result links the model can then WebFetch or cite.

Notebook

NotebookEdit

Edits a Jupyter notebook cell — adds, replaces, or deletes a code or markdown cell at a given index. The model reaches for it when working in .ipynb files, where Edit on the raw JSON is fragile and NotebookEdit is structured. Permission implications: same scope as Edit on the underlying file path.

When it surfaces: "Editing notebook cell 3 in analysis.ipynb" — NotebookEdit firing. The output reflects the cell change in the notebook UI if one is attached.

Where to read more

Every tool above has a deeper section in the official Claude Code docs at docs.claude.com/en/docs/claude-code/. Two pages worth bookmarking: the setup page (mentioned in Part 1) and the hooks reference (which couples to Part 5 once you start gating tools by event).

The inventory shifts. New tools land, old ones change shape, schemas evolve. Run /help and skim the docs index every couple of release notes; nothing in this article should be quoted as a permanent contract. The shape of the categories — file, shell, task-tracking, interaction, composition, scheduling, web, notebook — is more stable than any specific name in any specific category.

What just changed

You started this part not knowing exactly which tool was firing when Claude Code said "Reading file" or "Running command." You finish with:

• A rough mental map of the fifteen tools Claude Code ships with, organised by category.
• A handle on which tools are gated by which permission patterns in .claude/settings.json.
• A pointer (TodoWrite) that lands on Part 7's Plan phase by name — the persistence surface every plan rides on.
• A reading list at docs.claude.com/en/docs/claude-code/ for anything beyond what is here.

The catalogue is reference material. It is the part of the series you come back to when a tool surface confuses you mid-session.

What is next

Part 7 — Plan, Control, Execute, Validate ties everything together. The four-phase method maps each phase onto the primitives you have authored: Plan onto TodoWrite and plan mode, Control onto Skills and subagents, Execute onto Bash and the file tools, Validate onto reviewer subagents and Stop hooks. The shape is older than AI; the surfaces are what Claude Code makes concrete.