Claude Code Built-in Tools

Claude Code ships with a small, powerful set of built-in tools that let the model explore and edit a codebase directly: Glob, Grep, Read, Write, Edit, and Bash.

As an architect, your job is not just to know what each tool does, but to know which tool to reach for at each step of an investigation. Picking the right one keeps context lean and the agent fast.

• Glob — find files by name pattern
• Grep — search file contents
• Read — load one file
• Write — create a file
• Edit — make a precise change
• Bash — run a shell command

Glob locates files by their name or path pattern, not their contents. It is the fastest way to answer "where are the X files?"

Patterns use standard glob syntax: ** matches any depth of directories, * matches within a segment. Reach for Glob before reading anything — it narrows a huge tree down to the handful of files worth opening.

Grep searches inside files for a string or regular expression. Use it to find where a function is defined, where a symbol is used, or which files mention a feature flag.

The key distinction to memorize for the exam: Glob matches file names; Grep matches file contents. Confusing the two is a classic misroute.

Read loads the contents of a single file into context so the model can reason about it. After Glob or Grep has narrowed the candidates, Read brings the relevant file in.

Be deliberate: every file you Read consumes context window. Reading dozens of large files dilutes attention and triggers the lost-in-the-middle effect, where the model attends to the start and end of context far more than the middle. Read only what the investigation actually needs.

Write creates a new file (or fully overwrites one) with the content you supply. Use it when you are producing something from scratch — a new module, a config file, a test suite.

For changing an existing file, prefer Edit: it makes a surgical, reviewable change instead of rewriting the whole file. Reserve Write for genuinely new content or a deliberate full replacement.

Edit performs a precise change by matching a unique string in the file and replacing it. Because the match must be unique, it makes edits safe and reviewable — you change exactly the intended line, nothing else.

The exam-critical rule: if the target string is not unique, the Edit fails. The correct fallback is to Read the file for more surrounding context to build a unique match, or to Write the file if a full replacement is cleaner. Do not blindly retry the same ambiguous edit.

Bash runs shell commands: build, test, lint, git, package managers, or any CLI. It is the escape hatch for everything the dedicated tools don't cover.

Idiomatic practice: use the dedicated tool when one exists. Prefer Grep over bash grep, Read over cat, Glob over find — they return structured, model-friendly results. Save Bash for genuine shell work like running the test suite or a git operation.

Built-in tools shine when chained into an incremental investigation rather than dumping the whole codebase into context. The canonical loop:

1. Grep the entry points to find where behavior originates
2. Read those files to understand them
3. Grep for usages of the symbols you found
4. Read the consumers that matter

Each step narrows the search before the next widens it. This keeps context focused and avoids the lost-in-the-middle problem.

In the certification's Developer Productivity scenario, built-in tools are the foundation of fast, focused work. The architect's instinct is to scope each tool to the step and avoid loading more than needed.

When the repo's built-in tools aren't enough — you need a database schema, an issue tracker, or an external catalog — you reach for MCP servers, which extend Claude Code with additional tools and read-only resources. Built-in tools cover the local filesystem; MCP covers everything outside it.

When you put these tools behind a subagent or skill, grant only what the role needs. A read-only review agent should get Glob, Grep, and Read — not Write, Edit, or Bash.

This matters because 4–5 tools per agent is optimal; piling on 18+ degrades selection reliability. Restricting the toolset both enforces safety and sharpens the model's choices. In a skill, the allowed-tools frontmatter field does exactly this.

These same tools power non-interactive runs in a pipeline. With -p / --print Claude Code runs headless, and --output-format json makes results parseable for the CI step that follows.

For pre-merge review, run in an isolated session — a fresh review is less biased than self-reviewing in the same session that generated the code. And use a blocking, synchronous call here: the Batch API (50% cheaper, up to 24h, no latency SLA) is for overnight audits, never for time-sensitive pre-merge checks.

You are tracing where a function named process_refund is called across an unfamiliar TypeScript repo, then you need to change one specific call site whose surrounding code is identical to three others. Which approach is correct?

Key takeaways for the exam:

• Glob = find files by pattern; Grep = search file contents — never confuse the two.
• Read loads a file; read only what you need to avoid lost-in-the-middle.
• Write creates/overwrites; Edit makes a precise unique-match change. If the match isn't unique, Read for more context (or Write a full replacement) — don't blindly retry.
• Bash is for real shell work; prefer dedicated tools over grep/cat/find.
• Chain them incrementally: Grep entry points → Read → Grep usages → Read consumers.
• Apply least privilege (4–5 tools, read-only for reviewers); in CI use -p + --output-format json in an isolated session, and never the Batch API for blocking checks.