Pillar 4 - Tools
Tools are the actions an agent can take. The biggest mistake is giving it too many - fewer, clearer tools beat a giant cluttered toolbox
What Tools Are, in Context Terms
Tools are the actions an agent can take in the world: run a command, search files, query a database, send a message. In Level 1 you learned tools let agents do things. Here's the context-engineering angle: every tool you give the agent also costs context.Each tool's description sits on the desk, taking up the attention budget, whether or not it's ever used.
The #1 Failure: Bloated Tool Sets
Anthropic names this as one of the most common failure modes they see, and it's worth memorizing the rule because it's blunt and useful:
When you hand the model two tools that overlap - say
search_files and find_in_repo that do almost the same thing - you force it to burn a turn deciding, and it'll sometimes pick wrong. Ambiguity is the enemy.What Good Tools Look Like
The same qualities that make a tool good for a human teammate make it good for an agent:
The smallest set that covers the job, with no two tools competing for the same situation. When in doubt, cut a tool.
A tool should return useful, compact results - not a 4,000-line dump. If a tool floods the desk every time it's called, it'll wreck the budget.
A self-explanatory name and description, with unambiguous inputs. The model should never have to guess what a tool does or which one to reach for.
Good tools give helpful errors ("path not found, did you mean...") so the agent can recover instead of spiraling.
Fewer Tools, Better Agent
The instinct is to give the agent every capability up front, "just in case." Resist it. The right number of tools is almost always smaller than your first version shipped with.
BLOATED (12 tools) TIGHT (4 tools) search_files search ← one clear search find_in_repo read_file grep_code run_command semantic_search open_pr read_file cat_file ← overlap! Easy for the model to choose. view_document Every tool earns its desk space. run_command exec_shell ← overlap! open_pr create_pull_request ← overlap! ...the model wastes turns choosing
MCP: How Tools Plug In
You met MCP (Model Context Protocol) in Levels 1 and 7 - the "USB port" standard for connecting tools to agents. In context-engineering terms, MCP is how the tool pillar is wired up: a standard way to expose a search, a database, or an API as a tool the agent can call. The same context-budget rules apply: just because MCP makes it easyto add 30 tools doesn't mean you should. Add the few that earn their place.
The Four Pillars, Assembled
That completes the four pillars. Each is a different slice of the desk, and each follows the same north star from Lesson 66:
INSTRUCTIONS → the right altitude (clear, not brittle, not vague) RETRIEVAL → the right facts, just in time, not a data dump MEMORY → keep what matters, compact/note/isolate the rest TOOLS → few, clear, non-overlapping, token-efficient All four answer one question: how do I spend a finite attention budget to get the smallest high-signal desk?
Next lesson: how all four get assembled and pruned into the final context, every turn.
Hands-On: Cut the Toolbox
Every tool definition sits in the window using attention budget, whether or not it is used
The #1 tool failure - too many or overlapping tools force the model to waste turns choosing (and choose wrong)
If a human can't say which tool to use in a situation, the agent can't either - remove the ambiguity
Minimal, non-overlapping, token-efficient results, crystal-clear purpose, helpful errors
The right tool count is almost always smaller than your first version; when in doubt, cut one
The standard for wiring tools into agents - easy to add many, but the budget rules still apply