Identify the Tools an Agent Actually Needs
An agent is only as useful as the tools it can call — and only as safe as the tools it cannot. Learn to scope a tool surface from a task, distinguish read from write, and avoid the most common over-provisioning mistakes.
Identify the Tools an Agent Actually Needs
Before you wire up an MCP server or hand an agent a personal access token, ask the cheap question first: what tools does this task actually need, and what would happen if I gave it nothing else? The answer is your tool surface — and the discipline of keeping it small is the single biggest lever on agent safety, debuggability and cost.
Walk the task, name the verbs
A reliable trick is to write the task as a single sentence and underline every verb. Each verb maps to one tool. If you can't name a single tool for a verb, you have either too few tools (you need to add one) or too many (your tool is doing two jobs).
| Task verb | Right tool shape | Wrong tool shape |
| --- | --- | --- |
| "find issues labelled X" | search_issues(label, state) | execute_shell(cmd) |
| "comment on PR #N" | add_pr_comment(pr_number, body) | github_api(path, method, body) |
| "build the project" | run_build(target) | execute_shell(cmd) |
| "read this file" | read_file(path) | fetch(url) |
Named, typed tools are auditable. Generic shells are not. The exam returns to this trade-off repeatedly.
Read tools are not optional
Teams instinctively scrutinise write tools and casually ship read tools. That is backwards from a behavioural standpoint: a missing read tool is what makes an agent invent file contents, fake issue numbers, or stall on clarification questions. Provision reads liberally, scope writes narrowly.
Quick check
Quick check
A user asks the agent to 'summarise open bugs labelled regression and post the summary as a comment on issue #42.' Which minimum tool set should you provision?
Where this shows up on the exam
GH-600 will hand you a scenario task and four candidate tool lists. The right answer is almost never the longest list. Look for the option whose tools map one-to-one onto the verbs in the prompt — and reject any option that bundles write power into a read-shaped name.
Key terms
- Tool surface
- The exact set of functions an agent is permitted to invoke during a task. The smaller and more purpose-built, the safer.
- Read vs. write tool
- Read tools (search, list, get) cannot change state; write tools (create, update, delete, run) can. They demand different gating.
- Capability inflation
- Granting an agent a broad tool like 'execute_shell' when a narrow tool like 'run_unit_tests' would do the job.
- Task-to-tool mapping
- A deliberate exercise that lists the discrete actions a task requires, then names the single tool that performs each one.
Common pitfalls
- Giving the agent a generic 'shell' or 'browser' tool when a typed, named tool exists — you trade auditability for convenience.
- Forgetting that a missing read tool is a worse failure than a missing write tool: the agent will guess, hallucinate or loop instead of asking.
- Bundling read and write under the same permission grant so a 'list issues' capability silently includes 'close issue'.