#3 Claude Loops: Design the Tool Loop

How to expose the right tools, hide the dangerous ones, and use permissions so Claude Code can act without wandering. Claude Loops: Design the Tool Loop A workshop is not safer because every tool has a warning label. It is safer because the saw, soldering iron, and paint thinner are not all sitting on the same bench for every job. Claude Code has the same problem. The loop becomes powerful at the exact place it becomes capable of doing damage. Tools Turn Reasoning Into Action Why does the tool loop matter more than another prompt trick? Because tools are where Claude stops being only a model and starts becoming an operator. In Part 1, we looked at the basic loop: observe, act, inspect, repeat. In Part 2, we looked at the context loop: what stays inside the working window and what gets cleared, compacted, or forked away. Part 3 is about the action surface. Claude can answer directly, or it can call a tool. The Claude platform docs describe this as part of normal tool use: Claude evaluates the available tools and can decide when a tool is needed. In Claude Code, those tools are not abstract. They can read files, grep a repo, edit code, run shell commands, call MCP servers, launch subagents, and hand results back into the next turn. That is why a tool is not just a feature. It is a door. A tool loop is safe when Claude can reach the evidence it needs and cannot reach the power it does not. The Model Chooses From What You Expose Why does tool overload make Claude worse instead of better? Because every visible tool becomes part of the decision space. If Claude sees one file system, one shell, and one test command, the next move is relatively legible. If Claude sees fifteen MCP servers, browser automation, database tools, deploy commands, issue trackers, spreadsheets, and a pile of project-specific scripts, the loop has to decide not only what to do but which door is the right door. Sometimes that extra surface is useful. A product research loop may need Linear, GitHub, docs, and a browser. A local bug-fix loop probably does not need production Stripe, analytics exports, and a write-capable database connector. The point is not minimalism for aesthetics. The point is reducing wrong possible actions. Your job is not to show Claude every tool you own. Your job is to show Claude the smallest set of tools that can complete this task with evidence. Permission Rules Are the Harness What makes a tool boundary real instead of aspirational? Permissions. Claude Code’s permissions docs are unusually direct about this. Prompt instructions and CLAUDE.md can shape what Claude tries, but they do not change what Claude Code allows. Permission rules, permission modes, and PreToolUse hooks are what grant or revoke access. That distinction is the whole article. If your CLAUDE.md says “never push to main,” Claude may try to comply. If your permission rules deny Bash(git push *), the push is blocked by the harness. If your prompt says “do not read secrets,” Claude may avoid .env. If your permissions deny Read(./.env), Claude Code can enforce that boundary for the built-in read path. Guidance is useful. Enforcement is different. Permission ladder chart: allow, ask, deny Allow the Boring, Ask on Risk, Deny the Irrelevant How should you decide what goes in allow, ask, and deny? Start from the task, not the tool list. For a normal code fix, a good loop should not ask you before every status check. It should be able to run read-only inspection, test commands, and narrow lint commands without turning the session into a permission-dialog simulator. But broad writes, deploys, pushes, destructive migrations, and production access should create a human checkpoint or vanish entirely from the loop. The practical ladder is: allow routine and reversible actions ask before risky actions that might be necessary deny actions that should never be part of this task That is different from saying “trust Claude” or “do not trust Claude.” Trust is not the switch. Scope is the switch. Use Bare Denies to Hide Tools When should a tool disappear from Claude’s context completely? When using it would be wrong for the task even if Claude asked nicely. The permissions docs make an important distinction. A bare deny rule like Bash removes the tool from Claude's context entirely. A scoped rule like Bash(rm *) leaves Bash visible but blocks matching calls when Claude attempts them. That is a design choice. If this loop should never use MCP database tools, deny the MCP tools as a class or hide that server from the session. If this loop can use Bash but must not push code, keep Bash visible and deny the risky command pattern. Think of bare denies as removing a door from the room. Think of scoped denies as putting a lock on one kind of door handle. Both are useful. They solve different problems. Tool Search Is Better Than Tool Piles Why not preload every specialized tool and hope Claude picks the right one? Because the loop pays attention to the tools it can see. Claude Code supports deferred tool loading through tool search. Instead of putting every possible tool definition into context at startup, Claude can discover relevant tools when needed. That is the same pattern we used in Part 2 for context: keep the main window clean, then pull in what the task demands. This is especially important for MCP-heavy setups. A GitHub server, Slack server, database server, Notion server, browser server, and custom analytics server might all be useful somewhere. That does not mean every loop should see every tool description on every turn. Tool discovery is context hygiene for actions. The best tool surface is not the biggest one. It is the one that makes the next correct action obvious. Hooks Catch What Patterns Miss Where do permission patterns stop being enough? At the edge of messy reality. Command patterns are useful, but they are not a full policy engine. Claude Code’s docs warn that constraining things like network access through Bash command patterns can be fragile. A URL can move through variables, redirects, flags, or wrapper commands. A file can be touched indirectly by a script. That is where hooks matter. PreToolUse hooks let you inspect or block tool calls before they execute. They are useful when a simple allow or deny pattern is not expressive enough. Examples: block destructive database phrases in shell commands reject deploy commands outside a release branch require issue IDs before editing a regulated directory log every MCP call touching customer data block writes when tests are currently failing The hook is not there to make Claude smarter. The hook is there to make the loop less negotiable. Terminal GIF showing Claude Code permissions, allow rules, deny rules, and PreToolUse hook The Dangerous Mode Is Not Always the Loud One When do tool loops become risky in a way that feels innocent? But here’s the thing: the dangerous loop is not always the one that says “delete production.” Sometimes it is the loop with too many harmless tools. A read-only command can still fill context with irrelevant output. A browser tool can wander into research instead of fixing the bug. A GitHub tool can pull in ten issue threads when the failing test already named the cause. A write-capable MCP server can look like a convenience until Claude sees it as the fastest path. Risk is not only damage. Risk is drift. The loop starts with a small task, then the tool surface invites a larger one. Claude reads more, opens more, compares more, and returns with a plan that is technically impressive and operationally unhelpful. That is the quiet failure mode of tool overload. The tools were not dangerous one by one. The surface was too broad for the loop. Design Tools Per Task Phase How should the tool surface change as work moves from exploration to execution? By phase. Exploration needs broad read access, search, and maybe web or docs tools. Implementation needs narrow file reads, edits, and tests. Verification needs commands that prove the change worked. Release work may need GitHub, CI, changelog, and deploy tools, but only after the change is known. Do not treat those as one giant session with one giant tool surface. Give each phase the tools it needs: explore with reads and search implement with edits and local tests verify with test, lint, and diff release with explicit asks around push, deploy, and publish This is why permission modes matter. Plan mode is useful when Claude should explore without editing. Manual approvals are useful when you want to inspect first uses. More permissive modes belong in isolated environments where damage is contained. The right mode is not a personality trait. It is a runtime choice. The Tool Loop Contract How should you ask Claude when tool use should be intentional? Write the tool boundary into the request. Weak request: Code Fix the checkout bug. Better request: Code Use read-only inspection first. Do not call payment, production database, or deploy tools. Run the checkout test suite, inspect the smallest failing path, make the minimal local edit, rerun tests, and stop before any push. For a permissions-first session: Code Before editing, list the tools you expect to need. If a tool outside that set becomes necessary, ask before using it and explain why the loop changed. That prompt does not replace permissions. It makes the human intent legible while the harness enforces the real boundary. The third loop is simple: expose the smallest useful tool surface allow routine evidence gathering ask before risky actions deny irrelevant or dangerous doors use hooks when patterns are too weak change the tool surface when the task phase changes Part 4 will move from tools to verification: how to make Claude prove the loop worked before you trust the answer. Until then… — Sage 🍓 PS: Pick one Claude Code project and remove one tool or MCP server from the default session. If Claude only needs it once a week, it probably should not sit in every loop. Reference Notes Configure permissions Claude Code settings Automate actions with hooks Tool use with Claude Explore the context window Related Reading Claude Loops 1: Stop Using Claude Like Chat Claude Loops 2: Context Is the Hidden Loop Claude Code MCP Servers: How to Connect, Configure, and Use Them #3 Claude Loops: Design the Tool Loop was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.