Built-in tools: CCAR-F task statement 2.5

CCAR-F · Tool Design & MCP Integration (18% of the exam)

Task statement 2.5 sits in Tool Design & MCP Integration, 18% of the CCAR-F exam. It tests whether you can pick the right built-in tool for each step (Read, Write, Edit, Bash, Grep or Glob) and use them to understand a codebase without reading every file.

What the official guide covers

The Claude Certified Architect Foundations exam guide (version 1.0, effective July 2026) lists this under task statement 2.5, "Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively":

Knowledge of	Skills in
Grep searches file contents for patterns: function names, error messages, imports	Using Grep to find code across a codebase, such as every caller of a function or where an error message is raised
Glob matches file paths by name or extension pattern	Using Glob to find files by naming pattern, such as `*/.test.tsx`
Read and Write work on whole files; Edit makes targeted changes by matching unique text	Using Read then Write when Edit cannot find a unique anchor
When Edit fails because the text is not unique, Read plus Write is the reliable fallback	Building understanding step by step: Grep to find entry points, Read to follow imports, not reading everything up front
	Tracing usage through wrapper modules: list every exported name first, then search for each one

What each tool does

Tool	What it does	Typical use
Read	Returns a file's contents with line numbers. Also reads images, PDFs and Jupyter notebooks. Large files can be read in parts with `offset` and `limit`	Understand a file before changing it
Write	Creates a new file or overwrites an existing one with the full content given. It does not append or merge	New files, or replacing a whole file
Edit	Replaces an exact `old_string` with a `new_string`. No regex, no fuzzy matching	Small, targeted changes
Bash	Runs a shell command	Tests, builds, git, scripts
Grep	Searches inside files using ripgrep regex. Returns matching file paths by default, or matching lines, or counts. Can filter with a `glob` or a file `type`	Find where something is used or defined
Glob	Finds files whose paths match a pattern such as `src/*/.ts`	Find files by name or extension

The short version: Grep looks inside files, Glob looks at file names. If the question is "which files mention refundLimit?", that is Grep. If it is "which files end in .test.tsx?", that is Glob.

One platform detail. On macOS, Linux and WSL, Claude Code leaves Grep and Glob out of its default tool set and searches with grep and find through Bash instead. Naming Grep or Glob in --allowedTools or --tools, or in the Agent SDK's equivalent options, brings them back. The exam's choice is the same either way: search content for code, match names for files.

How Edit decides whether it can apply

Edit has to find old_string in the file exactly as written, and it has to find it exactly once.

Exact match. One space or indentation difference is enough to miss.
Unique match. If the text appears more than once, the edit does not apply. Claude can supply a longer old_string with enough surrounding lines to pin down one place, or set replace_all: true when every occurrence should change.

When no unique anchor exists, for example a file full of identical return None lines where only one should change, the guide's answer is to Read the whole file and Write the complete corrected version. Write replaces everything, so the full read comes first to make sure nothing is lost.

Explore a codebase step by step

Reading every file up front fills the context window with code that does not matter. The guide's pattern is incremental:

Grep for the thing you care about (a function name, an error string, a route) to find the entry points.
Read those files.
Follow the imports you find, reading only what the flow touches.
Repeat until you can explain the path.

Wrapper modules need one extra step. If billing/__init__.py re-exports calculate_tax as compute_tax, a search for calculate_tax misses every caller that uses the new name. List the wrapper's exported names first, then search for each one.

Worked example: find every caller of a tax function

The task: "Find every place that calculates tax so we can add a new region."

Step	Tool and input	What it shows
1	Grep `def calculate_tax`	Defined in `billing/tax.py`
2	Grep `from billing` with `output_mode: content`	`billing/__init__.py` imports it, plus 9 other files import from `billing`
3	Read `billing/__init__.py`	Re-exports it as `compute_tax` and wraps it in `tax_for_order`
4	Grep `calculate_tax\|compute_tax\|tax_for_order`	7 files, including 4 that never mention `calculate_tax`
5	Read the 7 files	Every call site, with context
6	Glob `*/test_tax*.py`	The test files to update alongside the change

Six steps and fewer than a dozen files read, instead of opening the whole repository. When the search itself is large (a whole service, an unfamiliar monorepo), hand it to a subagent: it reads the files in its own context and returns a summary, so the main session keeps room for the change.

Check the result after each change

Claude cannot see what an action did unless a tool shows it. The built-in tools cover both sides: Read before changing a file, then confirm the change landed. After an Edit, read the changed region or run the tests with Bash. After a Write, read the file back if anything else depended on its old content. A test command, a build or a linter gives Claude a pass or fail signal it can act on, which is far more reliable than judging its own diff.

Why the built-in set is general

Claude Code has no "refactor" or "install dependencies" tool. It has a small set of general tools, each with one clear job, and Claude combines them: Grep to find the code, Read to understand it, Edit to change it, Bash to run the tests. That is why exam answers about codebase work favour composing the built-in tools over writing a custom tool for each task.

The same contract appears if you build your own coding agent on the Messages API with Anthropic's text editor tool. Its str_replace command also needs old_str to match exactly and should hit exactly one location. The difference is that your application implements the commands (view, str_replace, create, insert), so the uniqueness check and the error message Claude sees are yours to write. For an Agent SDK agent that does this kind of work, give it the read-only search tools explicitly:

from claude_agent_sdk import ClaudeAgentOptions

options = ClaudeAgentOptions(
    allowed_tools=["Read", "Grep", "Glob"],   # explore without editing or running commands
)

Which tool to choose

Situation	Choose	Why
Find every file that calls a function	Grep	Searches file contents
Find all files named like `*.stories.tsx`	Glob	Matches paths, not contents
Change one line in a known file	Edit	Smallest change, nothing else touched
Edit fails because the text appears several times and only one should change	Longer `old_string` with context; if no unique anchor exists, Read then Write	Edit needs one exact match
Every occurrence should change	Edit with `replace_all: true`	One call, every match
Understand an unfamiliar module	Grep for entry points, then Read along the imports	Loads only what matters
Run tests or a build	Bash	Shell commands
Confirm an edit worked	Read the changed lines, or run tests with Bash	Claude only knows what a tool shows it
Exploration would read dozens of files	Delegate the search to a subagent	Its reads stay out of the main context
A team MCP tool searches better data than local files	The MCP tool, with a clear description	See 2.4 MCP server integration

Rules that decide exam answers

Grep for content, Glob for names. Options that swap them are the most common trap.
Edit needs one exact match. When it fails on duplicates, add context or fall back to Read then Write; retrying the same Edit will fail again.
Read before Write on an existing file. Write replaces the whole file, so start from its full current content.
Explore incrementally. Grep to find entry points, then Read along the flow. "Read every file first" is the wrong answer.
Trace through wrappers by exported name. Search for every name a wrapper exports, not only the original function name.
Verify, do not assume. After a change, a Read or a test run is the evidence. "The edit was applied" is not the same as "the code works".

Where it appears in the exam

Tool Design & MCP Integration is a primary domain in three of the six exam scenarios: Customer Support Resolution Agent, Multi-Agent Research System and Developer Productivity with Claude. Built-in tools fit Developer Productivity with Claude most closely; the guide describes that agent as exploring unfamiliar codebases with Read, Write, Bash, Grep and Glob.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A developer productivity agent is asked to list every place in a large monorepo where sendInvoiceEmail is called. Logs show it opening files one by one in src/, and it runs out of context before finishing. Which approach should it use?

A. Glob for **/*Invoice* and read every file it returns.B. Read every file in src/ in smaller batches across several sessions.C. Grep for sendInvoiceEmail across the repository, then Read only the matching files.D. Run the test suite with Bash and look for the function in the stack traces.

Answer: C. Grep searches file contents, so it finds every call site directly, and Read then loads only those files. A matches file names, which misses callers in files without "Invoice" in the name. B still reads everything. D finds only calls that tests happen to reach.

Question 2

An agent must change one return None inside a config loader. The file contains six identical return None lines, and the agent's Edit call keeps failing. It has retried the same Edit four times. What should it do?

A. Set replace_all: true so the Edit applies.B. Read the full file, then Write the complete file with only that one line changed.C. Use Glob to locate the file again, then retry the same Edit.D. Run a Bash sed command that replaces the first return None in the file.

Answer: B. Edit needs a unique match, and with no unique anchor, reading the whole file and writing it back is the reliable fallback. A changes all six lines. C finds the same file and the same duplicate text. D changes whichever line comes first, which may not be the right one.

Build exercise

In any real repository, pick a function used in several places. Find every caller with one Grep, then compare with what you would have found by reading folders by hand.
Use Glob to list all test files with a pattern such as **/*.test.*, then use Grep with a glob filter to find tests that mention one function.
Create a file with three identical lines. Ask Claude Code to change only the second one and watch how it handles the non-unique match.
Find a module that re-exports functions under new names. List its exports, then Grep for each name and count the callers you would have missed.

Practise this topic

Claude Certified Architect practice exam: free, 20 questions, no sign-up
Claude Certified Architect hub
CCAR-F study guide: all topics
Previous topic: 2.4 MCP server integration
Next topic: 3.1 CLAUDE.md hierarchy

Sources

Claude Certified Architect Foundations Exam Guide, version 1.0, effective July 2026 (Anthropic), task statement 2.5
Claude Code documentation: Tools reference
Claude Agent SDK documentation: Subagents in the SDK
Claude Code documentation: Best practices for Claude Code
Anthropic documentation: Text editor tool