The tradesperson reads the work order: "third-floor sink is leaking." Before climbing the stairs they ask one question — what does this job need? A wrench and a washer. Not the angle grinder, not the welding torch, not the electrician's meter.
Hauling the whole van up three flights would be slow — and handing a stranger a welding torch for a sink job is asking for a burnt kitchen. Picking the right minimum set of tools is the first move on every job.
An agent is the same. Before you configure or permission anything (lessons 2.2 on), you identify which tools the task requires — and, just as importantly, which it does not.
The idea, in plain English
A tool, for an agent, is a specific capability it can call to act: read a file, search the repo, edit code, run a shell command, fetch a URL, hand off to another agent. (The agent is the brain; tools are its hands, eyes, and phone.) Available tools are declared in the agent file's tools key (lesson 1.7), or restricted at run time with CLI flags.
Identify required tools = match a task to the smallest set of tools that can complete it. It comes before configuration and permissions — you can't grant least-privilege access until you know the minimum the job needs.
Two reasons it matters:
- Capability — if a task must run tests but you didn't grant
execute, it simply can't do the job. - Safety / least-privilege — every extra tool is extra blast radius. A review-only agent that can also
editandexecutecan do far more damage than its job requires (ties back to 1.3's contributor model; enforced in 2.2).
The tool families (know the shapes)
Think in families — what a tool does:
| Family | Lets the agent… | Needed when… |
|---|---|---|
read | inspect file contents | it must look at code before acting |
search | find files/text in the repository | it must locate the right code/file |
edit | modify / write files | it must change code |
execute | run shell commands (tests, scripts) | it must run or verify something |
agent | invoke another custom agent | it must hand a sub-task to a specialist |
The literal Copilot CLI tool values (what you actually type in tools: / --available-tools), in four groups:
- Shell —
bash(Unix) /powershell(Windows), + session variantslist_/read_/stop_/write_bash. (= theexecutefamily.) - File —
view(read a file/dir),create(new file),edit(string-replace),apply_patch(patch-style). (=read+edit.) - Agent/task —
list_agents,read_agent,task(run a subagent). (= theagentfamily.) - Other —
glob(find files by pattern),grep/rg(search text inside files),web_fetch(fetch a URL),ask_user(ask mid-run),skill(invoke a custom skill).
grep/glob/searchlook inside the repo.web_fetchreaches the internet. Not interchangeable — the study guide suggestswebis not a substitute forsearch, andsearchmeans repo/file search, not web search.editvscreatevsapply_patchall change files, but some models preferapply_patch— exclude it and those models may lose the ability to edit.ask_useris useless in the cloud agent (no human);powershellis absent in the cloud agent (Linux runners only). The context decides which tools even exist (lesson 2.5).
Match three tasks to a tool set
| Task | Minimum tools | Leave OUT (why) |
|---|---|---|
| "Summarize the open issues" (read-only) | view, grep (+ a GitHub read tool) | edit, apply_patch, execute — no changes, no shell |
"Add a unit test for utils.py" | view, grep, edit/apply_patch, bash | web_fetch, task — no internet, no subagents |
| "Research a library, then propose a fix" | web_fetch, view, grep, edit | execute if you don't want it running code yet |
Read-only review → no edit/execute. Code change → add edit + execute. Needs the internet → add web_fetch (which search/grep can't do). Start from the task, add the fewest tools that finish it, stop.
How you actually restrict them: the agent file's tools: list, or run-time flags --available-tools (allow-list) / --excluded-tools (deny-list). Configuring those is lesson 2.2 — here we only decide which. (Copilot can also auto-select tools, and you can force one by naming it in the prompt; skills — a SKILL.md folder loaded when its description matches the task — are a related way to add capability.)
The cert-language version
Identifying required tools means selecting, for a given task, the minimum set of capabilities the agent needs — across families like read, search, edit, execute, and agent — and excluding the rest. Tool selection is the first step of tool use, and it underpins least-privilege: an agent should be granted only the tools its scoped task requires.
Our summary · grounded in MS Learn — Agent tooling, MCP, and execution environments + GitHub Docs (Copilot CLI tool values) + naim149 study gist (verified tool families) · fetched 2026-05-30
Common confusions (read these or lose points)
- "More tools = better." No — more tools = more blast radius. Identify the minimum; extras are a least-privilege failure (2.2).
- "
search/grepcan read the web." No — they search inside the repo. The internet needsweb_fetch. (Study-guide-flagged trap.) - "Every agent has the same tools." No — the execution context decides: the cloud agent has no
ask_user(no human) and nopowershell(Linux only). Same agent file, different available tools (2.5). - "
editandapply_patchare interchangeable." Mostly — but some models only useapply_patch; excluding it can disable file edits for them.
Ticks this lesson done on the home roadmap. Saved in this browser.