Selecting and Applying Built-In Tools Effectively

Task statement 2.5 of the Claude Certified Architect — Foundations (CCA-F) exam — "Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively" — sits inside Domain 2 (Tool Design and MCP Integration, 18 % weight) and tests whether a candidate can pick the right tool for a given file-system or shell operation without over-reaching. The six built-in tools look small from the outside, but CCA-F scenario clusters rely on them heavily: every code-generation, developer-productivity, and CI/CD question implicitly assumes Claude is invoking Read, Write, Edit, Bash, Grep, or Glob with the correct choice, the correct parameters, and the correct safety posture. Misreading the tool boundary — using Write where Edit is required, using Bash where Glob suffices, using Grep where the question is about file discovery — is a high-frequency trap.

This study note walks through the full built-in tool surface a CCA-F candidate must recognize at the selection level: the inventory and purpose mapping, the precise contract of each tool, the Edit-versus-Write decision rule that dominates exam framing, the risk surface of Bash, the content-versus-path distinction between Grep and Glob, tool combination pipelines (Glob into Read into Edit for codebase refactor), performance trade-offs for bulk versus targeted operations, and the safety confirmations that separate a production-grade agent from a reckless one. A final traps section and seven-question FAQ anchor every concept back to the two scenarios that exercise built-in tools most heavily: developer-productivity-with-claude and claude-code-for-continuous-integration.

Built-In Tool Inventory — Six Tools, Six Distinct Purposes

Claude Code and the Claude Agent SDK ship with six canonical built-in tools. Each tool is narrowly scoped on purpose: narrow scope makes selection unambiguous, reduces the chance that Claude confuses one tool for another, and gives the exam a clean surface to test. The CCA-F expects you to map each tool to a single primary purpose and to know what the tool is not for.

• Read — Load the contents of a specific file into context. Optional line range. Not a search tool.
• Write — Create a net-new file or completely overwrite an existing file. Not a surgical edit tool.
• Edit — Make a surgical, in-place replacement inside an existing file. Not a file-creation tool.
• Bash — Execute an arbitrary shell command. The most powerful and the most dangerous built-in tool.
• Grep — Search file contents for a pattern (regex or literal) across many files. Not a filename search.
• Glob — Discover files by path pattern (globbing: **/*.ts, src/**/test_*.py). Not a content search.

The six tools form a closed set for the CCA-F exam: every scenario built around a file or shell operation maps to one of these six. If a scenario describes "reading the contents of config.json", the answer is Read. If it describes "finding every file that imports legacy_auth", the answer is Grep. If it describes "listing every .proto file under the api/ directory", the answer is Glob. Scenario authors deliberately use near-synonymous language to separate candidates who know the boundary from those who guess.

Why Built-In Tools Exist Separately from Bash

Bash is technically capable of reading, writing, editing, searching, and globbing files. You could, in principle, run an agent with only a Bash tool and achieve most of what Read, Write, Edit, Grep, and Glob achieve. The reason Anthropic exposes five specialized tools next to Bash is that specialized tools are safer, more observable, and easier for Claude to reason about than raw shell. A Read tool call records "Claude read this file, these line numbers, at this time" as structured metadata. A cat file.txt Bash call records only a shell string. Specialized tools narrow the blast radius of each action — Read cannot delete anything, Edit cannot create new files, Glob cannot mutate state — and make the agent's trajectory auditable. The CCA-F treats "use the specialized tool instead of Bash when one exists" as a baseline design expectation.

Read Tool — Loading File Contents Into Context with Line-Range Parameters

The Read tool loads the contents of a specified file into Claude's context window. Read is the default file-ingestion primitive: every time an agent needs to see what is inside a file — source code, configuration, documentation, logs — Read is the correct tool.

Read Tool Parameters

The key parameters exam scenarios exploit:

• file_path — An absolute path. Relative paths are not supported in most Agent SDK configurations.
• offset — Optional; the line number to start reading from. Used to read a window inside a large file.
• limit — Optional; the number of lines to read. Used together with offset to bound the read.

The offset/limit pair exists specifically to solve context-window pressure: a 50 000-line log file should never be read in one call. An agent that pulls only the relevant 200 lines avoids drowning the context window and preserves attention for the actual task.

When to Use Read

Read is correct whenever the agent needs the specific contents of a known file. Typical exam phrasings that map to Read:

• "The agent needs to examine the current value of config/database.yml."
• "The agent must view lines 200–250 of src/parser.ts to understand the existing implementation."
• "The agent needs to load package.json before deciding which scripts to run."

When NOT to Use Read

Read is not a file-discovery tool and not a content-search tool. If the scenario begins with "the agent does not know which file contains..." the answer is Grep (for content) or Glob (for name patterns), not Read. Scenario distractors frequently offer Read as a plausible wrong answer when the underlying operation is really search.

Write Tool — Creating New Files or Full Overwrite, and When Not to Use It

The Write tool creates a new file at a specified path or completely replaces the contents of an existing file. Write is an all-or-nothing operation: the entire file is written in one call; there is no concept of a partial write.

Write Tool Parameters

• file_path — An absolute path. If the file exists, its contents are fully overwritten. If it does not exist, it is created (with parent directories as needed, depending on SDK configuration).
• content — The full textual content to write.

When Write Is Correct

Write is correct in exactly two situations:

1. Net-new file creation — A file that does not exist yet is being created. Examples: scaffolding a new migration file, generating a fresh config, writing a brand-new test file that has no precursor.
2. Intentional full replacement — An existing file is being replaced entirely, and the replacement is not a surgical edit of the previous contents. Example: regenerating a lockfile, rewriting a build artifact, overwriting a placeholder template with real content.

When Write Is Wrong

Write is wrong — and this is the single most-tested point in task 2.5 — whenever the operation is a modification of an existing file. Modifying an existing file means the new content is a function of the old content: "change this function's return type", "add a new field to this struct", "replace legacy_client with new_client in the imports". These operations require Edit. Using Write for them is both unsafe (the full contents must be sent, and any transcription error silently drops code) and signals poor tool selection on the exam.

Why Full Overwrite Is Risky

A Write call that overwrites an existing file must re-emit every line Claude intends to keep. Any line Claude forgets, compresses, or subtly re-phrases is silently lost. For a 2 000-line source file, the probability of a perfect reproduction is not high enough to trust in a production system. Edit is safer because the unmodified lines are never sent — they remain as the filesystem has them. This asymmetry is the reason the exam insists on Edit for in-place changes.

Edit Tool — Surgical In-Place Modification, Preferred Over Write for Existing Files

The Edit tool performs a surgical in-place replacement inside an existing file. Edit sends only the "before" snippet and the "after" snippet; everything else in the file remains untouched by the filesystem.

Edit Tool Parameters

• file_path — An absolute path. The file must already exist; Edit does not create files.
• old_string — The exact literal snippet to replace. Whitespace and indentation must match.
• new_string — The replacement snippet.
• replace_all — Optional boolean; when true, replaces every occurrence. When false (default), the old_string must be unique in the file or the call fails.

When to Use Edit

Edit is correct for any modification of an existing file where the change can be expressed as a before/after string swap. Typical exam phrasings:

• "Update the timeout value in config.yml from 30 to 60."
• "Rename the function processData to normalizeData across all its definitions in parser.ts."
• "Replace the deprecated request.Legacy() call with request.V2() inside the handler."

Uniqueness Requirement

When replace_all is false, old_string must appear exactly once in the file. If the snippet is ambiguous (three functions named handle()), the Edit call fails and the agent must disambiguate — typically by including more surrounding context in the old_string (the function signature plus a distinctive first line). This uniqueness requirement is a safety feature: it prevents a well-intentioned rename from clobbering an unrelated line that happens to contain the same token.

Edit Preserves Unrelated Content

Because Edit sends only the delta, the rest of the file cannot be corrupted by Claude omitting, re-wording, or re-indenting lines. This is the structural reason Edit is safer than Write for modifications. Exam answers that frame Edit as "the safer choice for changing an existing file" are consistent with Anthropic's documented selection rule.

Edit vs Write Decision Rule — Edit When the File Exists, Write Only for Net-New

The selection between Edit and Write is the single highest-frequency judgment call in task 2.5. CCA-F scenarios are specifically constructed to reward candidates who have internalized the rule and to punish candidates who pattern-match on "we are writing to a file, so it must be Write".

The Rule in One Line

If the file already exists and the operation modifies part of it, use Edit. Use Write only for net-new files or a full intentional replacement.

Decision Tree

1. Does the file exist? If no, use Write. If yes, continue.
2. Is the intended change a full, intentional replacement of the entire file? If yes, Write is acceptable. If no, continue.
3. Is the change a modification of part of the file? Use Edit.

Why the Rule Exists

Three structural reasons:

• Safety — Edit cannot lose content Claude forgets to re-emit. Write can.
• Observability — An Edit call's diff is small and auditable. A Write call's "diff" is the entire file, which tooling cannot cheaply review.
• Cost and latency — Edit sends a small before/after pair. Write sends the full file content on every call, inflating token cost for large files.

Common Distractors

The exam will frequently offer four choices where Write appears alongside Edit for a modification scenario. Typical wrong-answer framings:

• "Write the updated file" — incorrect; use Edit for updates.
• "Overwrite the file with the new contents" — incorrect when only part is changing.
• "Re-emit the full file with the change applied" — incorrect; that is Write dressed up as Edit.

The correct answer on any modification scenario is Edit.

Bash Tool — Shell Command Execution, Risk Surface and Safety Considerations

The Bash tool executes an arbitrary shell command in a subprocess and returns the stdout, stderr, and exit code. Bash is the most powerful tool in the built-in set and, for the same reason, the most dangerous. CCA-F treats Bash as the tool of last resort: whenever a specialized tool (Read, Write, Edit, Grep, Glob) can express the operation, the specialized tool is preferred.

Bash Tool Parameters

• command — The shell command string to execute.
• timeout — Optional; a per-call wall-clock limit. Important for long-running builds or test suites.
• description — A short human-readable label describing the command's intent. Used for logging and audit.

What Bash Is Actually For

Bash is the correct choice when the operation is genuinely a shell command with no specialized equivalent:

• Running builds and tests — npm test, pytest, cargo build, make lint.
• Invoking version-control commands — git status, git log, git diff (some SDK setups expose these through dedicated tools; check the reference).
• Managing processes and services — systemctl, docker compose up, kill.
• One-off shell utilities without a Claude Code equivalent — curl against an internal endpoint, jq post-processing, awk column extraction on a structured log.
• Package manager operations — pip install, npm install, apt-get update.

What Bash Is Not For

Bash should not be used when a specialized tool exists for the same operation:

• Reading a file → Read, not cat.
• Writing a file → Write or Edit, not echo > file or sed -i.
• Searching contents → Grep, not grep shelled out through Bash.
• Listing files by pattern → Glob, not find shelled out through Bash.

Using Bash where a specialized tool suffices widens the blast radius (Bash can execute any command), weakens observability (the intent is buried in a shell string), and is treated on the exam as poor design.

Risk Surface

Bash commands can:

• Delete files (rm -rf).
• Mutate configuration (sed -i, echo >).
• Send network traffic (curl, wget, ssh).
• Consume unbounded resources (a runaway tail -f or dd).
• Exfiltrate data (any command that reads local files and ships them elsewhere).

Because of this, production agents running Bash should combine an allow-list of acceptable commands, per-call timeouts, and — for destructive or unbounded operations — explicit human approval before execution.

Grep Tool — Pattern Search Across Files, Regex vs Literal, Context Lines

The Grep tool searches the contents of files for a pattern. Grep returns the matching lines together with their file paths and line numbers. Grep is the go-to tool for the question "which files contain X" or "where does this symbol appear" across a codebase.

Grep Tool Parameters

Typical parameters (subject to SDK-specific variation):

• pattern — A regular-expression or literal string to search for.
• path — An optional directory or file to scope the search. Without it, Grep searches the entire working directory.
• output_mode — Controls how matches are returned (lines with paths, paths only, counts only).
• -i / case-insensitivity — Optional case-insensitive match.
• -n / line numbers — Include line numbers with each match.
• -A / -B / -C — Context lines after / before / around each match. Useful for seeing the surrounding function or block.
• glob — Restrict to files matching a path pattern (for example, *.ts).

When to Use Grep

Grep is correct when the question is "which lines or files contain this pattern". Typical exam phrasings:

• "Find every usage of process.env.API_KEY across the codebase."
• "Locate the definition of the UserSession interface."
• "List all files that import the deprecated utils/legacy.ts."
• "Find the line where the error message invalid token is raised."

Regex vs Literal

Grep supports regular-expression patterns. Anchoring (^, $), character classes ([A-Z]), and capture groups all work. For simple literal strings — say, finding every occurrence of the exact filename schema.sql — a literal search is faster and avoids accidental regex interpretation (a literal $ in the pattern would match end-of-line if interpreted as regex). Use the literal form when the pattern is known to be exact; use regex when you need flexibility.

Context Lines Matter on Exam

Context flags (-A, -B, -C) are frequently overlooked but are the mechanism by which an agent sees a match in its surrounding block. Reading only the matching line often produces out-of-context decisions; reading -C 3 (three lines on each side) is often the right default. Scenario questions that describe the agent "understanding the function that contains the match" generally imply context lines.

Glob Tool — File Discovery by Pattern, When to Prefer Over Bash find

The Glob tool discovers files by path pattern. Glob returns the list of matching file paths, typically ordered by modification time (newest first). Glob is the go-to tool for "find all .ts files" or "list every test file under this directory".

Glob Tool Parameters

• pattern — A glob-style path pattern. Standard wildcards: * (any chars within a segment), ** (any depth of directories), ? (single char), character classes. Examples: **/*.ts, src/**/test_*.py, docs/**/*.md.
• path — Optional root directory to glob from. Without it, Glob operates on the working directory.

When to Use Glob

Glob is correct when the question is "which files exist at paths matching this pattern". Typical exam phrasings:

• "List every .proto file under the api/ directory."
• "Find all test files matching test_*.py in the project."
• "Discover every markdown document under docs/."
• "Enumerate every YAML configuration file in the repository."

Glob vs Bash find

Bash's find utility can accomplish everything Glob accomplishes. The reason CCA-F prefers Glob over find is identical to the general rule for specialized tools: Glob is narrower, safer, more observable, and does not widen the blast radius to arbitrary shell execution. A find call can be piped into rm, mv, or any other destructive command; a Glob call cannot. On the exam, "use Bash find to list files" is a deliberately placed wrong answer when Glob is the correct tool.

Glob vs Grep — The Content/Path Boundary

The single most-tested Grep/Glob distinction:

• Grep searches inside file contents for a pattern.
• Glob searches file paths for a pattern.

A question phrased "find all files that mention UserSession" is Grep (content). A question phrased "find all files named user_session.ts" is Glob (path). Exam distractors routinely flip these two to test whether a candidate has internalized the boundary.

Tool Combination Patterns — Glob → Read → Edit Pipeline for Codebase Refactoring

Built-in tools are designed to compose. The most important composition on the CCA-F exam is the Glob → Read → Edit pipeline, which is the canonical shape of an autonomous codebase refactor.

The Canonical Refactor Pipeline

1. Glob — Enumerate the files that may be affected. Example: **/*.ts to list all TypeScript files under the repo.
2. Grep (optional) — Narrow the list to files whose contents mention the symbol being refactored. This avoids reading unrelated files and keeps context manageable.
3. Read — Load the contents of each candidate file (usually with line ranges around the match) so Claude can reason about the surrounding code.
4. Edit — Apply the surgical change to each affected region.

Why Pipelines Beat Monolithic Bash

A naive alternative is a single Bash call: find . -name '*.ts' -exec sed -i 's/oldName/newName/g' {} +. This is faster in wall-clock terms but:

• It gives Claude no chance to inspect the candidate occurrences.
• It cannot distinguish a valid rename target from a false positive (for example, a comment or a string literal).
• It bypasses the audit trail that specialized tool calls create.

The pipeline version takes longer but is safer, observable, and much more accurate — which matches what production agents actually need and what CCA-F rewards.

Parallel Reads Inside the Pipeline

Modern Claude models aggressively parallelize tool calls when they are independent. When a refactor needs to read five candidate files, Claude will frequently emit five Read tool_use blocks in a single assistant message. The corresponding user message must contain five matching tool_result blocks. An implementation that serializes these reads into five separate turns wastes latency and violates the standard pattern. This ties directly to task 1.1 (agentic-loop design) and shows why the two tasks are commonly tested together.

Grep-First vs Glob-First

When the target set is large (all .ts files in a monorepo: thousands), starting with Grep is often better than starting with Glob — Grep's output is already narrowed to files that actually contain the symbol, and Grep can include the matching line numbers so the subsequent Read calls can use offset/limit to load only relevant windows. When the target set is small (a single directory of config files), Glob-first is simpler. The exam rewards matching the order to the size of the working set.

Performance Considerations — Bash for Bulk Ops, Grep for Search, Read for Targeted Loads

Built-in tools have different performance characteristics, and choosing the wrong tool for the scale of the operation is a common exam trap.

Read — Targeted, Small Loads

Read is designed for loading a bounded region of a single file. Loading a 200-line slice of a file is cheap; loading a 50 000-line file in one Read call is expensive and pollutes context. Always scope Read with offset and limit when the file is large. For scanning every file in a repo one at a time, Read is the wrong tool — the pattern is Glob (or Grep) first, then Read the narrow set.

Grep — Bulk Content Search

Grep is optimized for scanning contents across many files. A Grep call across a repository is far more efficient than reading each file with Read and searching in-context. When the operation is "find the files that contain X", Grep is not just the right semantic choice — it is the right performance choice.

Glob — Bulk Path Discovery

Glob is optimized for returning a list of matching file paths quickly. Asking Glob for all .ts files in a 10 000-file repo is trivial; asking Read to list files by iterating directories is impossible (Read is not a directory tool).

Bash — Bulk Operations Without a Specialized Tool

Bash is the right tool when the bulk operation has no specialized equivalent — running an entire test suite, installing 200 dependencies, invoking a code generator. When the bulk operation is "search contents" or "list files by pattern", Grep or Glob is correct and Bash is wrong.

When Scale Flips the Answer

Two examples where the size of the working set flips the correct tool:

• Reading one file → Read. Reading a thousand files → usually Grep first to narrow, then Read selectively.
• Editing one line → Edit. Editing the same line across hundreds of files → a tight Glob → Read → Edit pipeline, or — in constrained cases — a single Bash command with human review. The Edit-centric pipeline is the default CCA-F answer because it preserves auditability.

Safety and Destructive Operations — Confirming Intent Before Write/Bash Execution

Three of the six built-in tools can mutate or destroy state: Write, Edit, and Bash. A production agent must treat their execution with more care than read-only tools. CCA-F scenarios test whether candidates design that care into the agent's loop.

The Three Mutating Tools and Their Blast Radius

• Write — Full-file overwrite. Irrecoverable at the filesystem layer unless version control catches it.
• Edit — In-place modification. Narrow blast radius (one before/after swap) but still irrecoverable outside version control.
• Bash — Arbitrary command. The blast radius is the union of everything the shell can reach — filesystem, network, spawned processes.

Permissions and Allowlists

Claude Code lets a configuration declare which tools are permitted in a given context and, for Bash, which command patterns are permitted. An agent running in a CI pipeline might allow Read/Grep/Glob freely, require explicit approval for Write/Edit, and restrict Bash to an allowlist such as npm test, npm run build, and git status. This pattern — the tiered permission model — is the Anthropic-recommended default for autonomous agents.

Human-in-the-Loop for Destructive Actions

For operations whose blast radius exceeds what automated rollback can handle — production database writes, destructive shell commands, deployments to live infrastructure — the agent should pause and request human approval before execution. This ties to plan mode (task 3.4) and to human review workflows (task 5.5), but it is a built-in-tool concern because the mechanical pause is invoked when a Write/Edit/Bash call is about to fire.

Dry Runs and Plan Mode

Plan mode (task 3.4) lets an agent propose what it would do — which Write calls, which Edit calls, which Bash invocations — without actually running them. A user approves the plan, and only then does execution begin. Plan mode is not automatically the safer choice (it adds latency and breaks non-interactive pipelines), but for destructive multi-file refactors it is the correct default.

Built-In Tools in CI/CD Non-Interactive Mode

The claude-code-for-continuous-integration scenario exercises built-in tools inside automated pipelines where no human is watching. The built-in tool selection rules do not change, but the safety posture does.

Non-Interactive Execution with the -p Flag

When Claude Code runs inside CI (GitHub Actions, GitLab CI, Buildkite), it is invoked in non-interactive mode (commonly with the -p flag). The agent cannot pause for human approval. Consequently, the allowlist model becomes the primary safety mechanism: every Bash command pattern the agent is permitted to execute must be declared up front; any command outside the allowlist aborts the run.

Read-Only Inspection Jobs

Many CI jobs are read-only: lint checks, security scans, dependency audits. For these, an agent configuration that permits only Read, Grep, and Glob — and denies Write, Edit, Bash — is appropriate. The narrow permission set is itself a safety feature: even if the agent misbehaves, it cannot mutate the codebase.

Code-Generating CI Jobs

Jobs that regenerate code artifacts (running codegen from a .proto file, updating a generated SDK) legitimately need Write and occasionally Edit. Bash is commonly required to invoke the code generator itself. Each mutating tool's scope should be narrowed (Write allowed only under a generated/ directory, Bash allowed only for a specific codegen command).

Deployment Jobs

Jobs that deploy to production should almost never run Bash freely. The typical pattern is an allowlist of exactly the deployment commands (for example, kubectl apply -f deploy.yaml), no others. Plan mode is not available in non-interactive CI, so the allowlist is the primary control.

Observability — Logging Built-In Tool Calls

Every built-in tool call is a structured event that a production agent should log. The minimum logging surface:

• Tool name — Read, Write, Edit, Bash, Grep, Glob.
• Input arguments — file_path, pattern, command, etc. For Bash, log the full command string; for Edit, log the old_string / new_string pair (or at least their lengths for privacy-sensitive code).
• Timestamp and duration — when the call fired and how long it took.
• is_error — whether the tool reported failure.
• Result preview — a truncated snapshot of the return value for audit.

The Agent SDK's PreToolUse and PostToolUse hooks (task 1.5) are the clean place to attach this logging. In Claude Code, settings-level logging handles the same job. Observability is not a built-in-tool concept per se, but no CCA-F answer about built-in tool selection is complete without acknowledging that the selected tool's call must be auditable.

Plain-English Explanation

Built-in tool selection becomes intuitive when you anchor the six tools to physical systems that already separate responsibilities the same way. Three analogies cover the full surface.

Analogy 1: The Workshop Toolbox — One Job Per Tool

Picture a well-kept carpenter's workshop. On the pegboard you see six specific tools: a magnifying glass (Read), a pen (Write), an eraser and pencil (Edit), a power drill (Bash), a directory index (Grep), and a file cabinet finder (Glob). A careful carpenter never uses the drill to write a label, never uses the eraser to build a new drawer from scratch, and never uses the magnifying glass to search the cabinets. Each tool is there precisely because the others would be overkill or unsafe for that job. When a customer asks "where did I store that blueprint?", the carpenter reaches for the file cabinet finder, not the drill. When the customer asks "what is written on the third page of blueprint 17?", the carpenter reaches for the magnifying glass, not the index. The power drill can technically do anything with enough attachments — but a competent carpenter only reaches for it when the specialized tool cannot. That is exactly the CCA-F selection rule: reach for the specialized tool first; reach for Bash only when nothing else fits.

Analogy 2: The Library Catalog — Path vs Content Is a Fundamental Separation

Walk into a research library. There are two distinct search systems. One catalog indexes books by their titles and call numbers — this is Glob. Another catalog indexes books by the keywords inside their text — this is Grep. If you ask the librarian "do you have a book called Introduction to Algorithms?", they walk you to the title catalog (Glob). If you ask "which books discuss Dijkstra's algorithm?", they walk you to the content catalog (Grep). These are not interchangeable. A title search cannot tell you what is inside a book; a content search cannot enumerate every book that exists. Novice researchers confuse the two and get frustrated when the title catalog returns zero results for "Dijkstra's algorithm" — because no book is titled that phrase, even though dozens contain it. CCA-F candidates who flip Grep and Glob make the exact same mistake. Grep reads insides; Glob reads spines.

Analogy 3: The Kitchen — Edit vs Write Is About Preserving What Is Already There

A chef adjusting the seasoning on a finished sauce has two options. Option A: taste the sauce, decide it needs more salt, and add a pinch (this is Edit — small, surgical, preserves everything else). Option B: dump the whole pot and make a brand-new sauce from scratch (this is Write — intentional full replacement). Option B is sometimes right — if the sauce is actually broken and cannot be salvaged, you start over. But Option B for a seasoning tweak is reckless: you are reproducing the entire recipe from memory and any small error (forgetting a spice, mis-measuring the liquid) silently corrupts the dish. The same logic applies to file modifications. If you are changing one function, you do not re-write the whole file; you Edit. If you are generating a brand-new configuration file that did not exist before, you Write. CCA-F scenarios test exactly this instinct: does the candidate know that preserving what is already there is safer than re-emitting it?

Which Analogy Fits Which Exam Question

• Questions about which built-in tool to pick → workshop toolbox analogy.
• Questions about Grep vs Glob → library catalog analogy.
• Questions about Edit vs Write → kitchen seasoning analogy.

Common Exam Traps

CCA-F task 2.5 consistently exploits six trap patterns around built-in tool selection. All six are documented in community pass reports and appear disguised as plausible distractors.

Trap 1: Using Write to Modify an Existing File

The highest-frequency trap. The scenario describes updating, renaming, replacing, or inserting inside an existing file, and one of the four choices is "Write the file with the new contents". Write is wrong on any modification of an existing file. Edit is the answer.

Trap 2: Using Bash When a Specialized Tool Exists

Scenarios offer "use Bash to cat the file" or "use Bash find to list files" or "use Bash grep to search contents" as plausible-looking options. When Read, Glob, or Grep exists for the operation, Bash is wrong — not because it fails, but because it needlessly widens the blast radius. The specialized tool is always preferred.

Trap 3: Flipping Grep and Glob

Grep searches contents. Glob searches paths. Scenarios deliberately describe a content-shaped question ("find every file that imports legacy_auth") and offer Glob as a distractor, or a path-shaped question ("list every .proto file") and offer Grep as a distractor. Read the question once for the verb (mentions, contains, imports → Grep) or the pattern shape (*.ts, **/*.py → Glob) and pick accordingly.

Trap 4: Treating Edit as a File-Creation Tool

Edit requires the file to already exist. Scenarios occasionally offer Edit for a net-new file (scaffold a new test, generate a new config). On a fresh file, Edit fails because there is no old_string to match. The correct tool for creating a net-new file is Write.

Trap 5: Skipping the Pipeline for a Monolithic Bash Command

For a cross-file refactor, the exam rewards the Glob → Read → Edit pipeline, not a single Bash call with sed -i. Even though the Bash one-liner is shorter, it is less observable, less safe, and less accurate. Scenario answers framed as "one Bash call to do the whole refactor" are almost always wrong in favour of the specialized pipeline.

Trap 6: Omitting Offset and Limit on Read for Large Files

Reading a 50 000-line log file with no offset / limit floods the context window and typically fails downstream tasks. Correct Read calls on large files include offset/limit (or are preceded by Grep to identify the line numbers of interest). Answers that perform an unbounded Read on a large file are treated as incorrect design even when Read is the right tool category.

Practice Anchors

Built-in tool selection questions cluster in two of the six CCA-F scenarios. Treat the following as the architecture spine.

Developer-Productivity-With-Claude Scenario

This scenario's whole premise is that a developer uses a Claude-driven agent to work across a large codebase — bug investigations, multi-file refactors, test authoring, documentation updates. Built-in tools are the primary interface between the agent and the codebase, and almost every question exercises one of them. Expect questions that test:

• The Glob → Read → Edit refactor pipeline.
• Grep vs Glob selection (find a symbol's uses vs list files by path pattern).
• Edit vs Write selection (modify an existing function vs create a new test file).
• Bash reserved for build/test invocations, not for file reads or searches.
• Read with offset/limit for large files vs unbounded reads.

Claude-Code-For-Continuous-Integration Scenario

This scenario pushes the built-in tools into automated non-interactive contexts. The selection rules are the same, but the safety posture shifts to allowlists and narrow permission scopes. Expect questions that test:

• Tool permission scoping in CI (which tools the agent is allowed to use).
• Bash allowlist design (exact command patterns permitted).
• When to permit Write/Edit (codegen jobs only) vs deny them (lint-only jobs).
• -p non-interactive flag for CI invocation, together with built-in tool configuration.
• Detecting and rejecting destructive Bash calls outside the allowlist.

Scenario authors sometimes cross-reference the two scenarios: a refactor that is triggered by CI still uses the same tools, but with a narrower permission set than the developer's interactive session.

FAQ — Built-In Tools Top 6 Questions

How do I decide between Edit and Write for a file modification?

Use Edit whenever the file already exists and the operation is a modification of part of the file. Use Write only for net-new files or for an intentional full-file replacement. Edit is safer because it sends only the before/after snippets and preserves the rest of the file at the filesystem layer — Claude never has to re-emit lines it is not changing. Write on an existing file forces Claude to reproduce every line, and any line dropped or re-phrased in transcription is silently lost. CCA-F treats Edit-for-modification as the correct answer and Write-for-modification as a deliberately placed distractor.

What is the difference between Grep and Glob on the exam?

Grep searches the contents of files for a pattern; Glob searches file paths for a pattern. The boundary is the single most-tested distinction in the Grep/Glob pair. Typical Grep prompts sound like "find every file that mentions or imports or contains X" — the verb points inside the file. Typical Glob prompts sound like "list every file named *.ts" or "find all files under src/" — the verb points at the path. An answer that uses Grep for a path-shaped question or Glob for a content-shaped question is wrong regardless of how the pattern is written.

When should I use Bash instead of one of the specialized tools?

Use Bash when the operation is genuinely a shell command with no specialized equivalent — running a build, running a test suite, invoking a package manager, driving a one-off utility like jq. Never use Bash for an operation that a specialized tool already covers. cat file.txt is Read; echo > file.txt is Write; sed -i is Edit; grep is Grep; find is Glob. Picking Bash over the specialized tool widens the blast radius to arbitrary shell, weakens observability (the intent is buried in a shell string), and is treated on the exam as poor tool selection.

Can Edit create a new file if I pass the right old_string and new_string?

No. Edit requires the file to already exist. There is no old_string to match on a non-existent file, so the call fails before any replacement logic runs. The correct tool for creating a net-new file is Write. CCA-F scenarios occasionally offer Edit for a fresh scaffold as a distractor — the boundary (Edit modifies, Write creates) is a deliberate exam gate.

Why is Read slower or more expensive than Grep when searching across files?

Read loads the full specified range of a specific file into context. Using Read to "search" across many files would mean reading each file in full, token by token, with Claude reasoning about the contents. That is expensive both in latency and in context pressure. Grep runs a fast filesystem-level scan, returns only the matching lines, and lets the agent make a narrow subsequent Read call with offset/limit for the specific match window. For "which files contain X" questions, Grep is the correct tool; Read is for loading known regions of known files after the search has completed.

What safety measures should I attach to Write, Edit, and Bash calls in a production agent?

Three layers. First, a permission allowlist declaring which tools the agent may use in the current context — for example, a lint-only CI job may permit only Read/Grep/Glob. Second, for Bash, an allowlist of exact command patterns (for example, npm test, npm run build) so that arbitrary shell cannot execute. Third, for destructive or high-stakes operations, a human-approval gate before execution — invoked via plan mode in interactive sessions or via an explicit approval request in SDK-driven agents. CCA-F answers that combine tool capability with these safety controls are preferred over answers that rely on Claude's self-governance alone.

How do built-in tools interact with the agentic loop's stop_reason?

Every built-in tool invocation sits inside a tool_use block emitted by Claude with stop_reason: "tool_use". The agentic loop executes the tool (Read loads a file, Bash runs a command, etc.), wraps the output in a tool_result block with matching tool_use_id, and appends that result as a user message. The loop continues until Claude emits stop_reason: "end_turn" or a guard trips. This means built-in tool selection is mechanically coupled to task 1.1: an agent that picks the wrong tool (Write where Edit is required) still follows the same loop structure, but the semantic result is wrong. The exam tests both axes — correct loop shape and correct tool choice — in the same scenario.

Further Reading

• Tool reference — Anthropic-provided built-in tools: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/tool-reference
• Claude Code features overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Agent SDK overview: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

Related ExamHub topics: Tool Interface Design — Descriptions and Boundaries, MCP Server Integration with Claude Code, CLAUDE.md Files — Hierarchy, Scoping, and Modular Organization, Context Management in Large Codebase Exploration.