Narrow tools are safer because you can state, limit and audit exactly what each one does. A general shell or "fetch any URL" tool can do nearly anything, so it carries nearly every risk. Prefer one tool per job, and use open ended tools only inside a sandbox.
What OWASP says
OWASP's excessive agency guidance includes "avoid open-ended extensions" and gives the example of preferring tools with specific functions over ones that run a shell command or fetch any URL. It also lists minimizing extension functionality: build tools with only the functions the task needs.
Side by side
| Property | Narrow tool | General shell or fetch |
|---|---|---|
| What can it do? | One defined thing | Almost anything the host allows |
| Easy to scope? | Yes, by argument | Hard, you must filter strings |
| Approval prompt readable? | Yes, shows a clear action | A command string few people parse |
| Audit value | High, clean events | Low, free text commands |
| Build cost | Higher up front | Low, until the first incident |
When a shell is the right call
Coding agents often need a shell, and the sensible answer is containment, not refusal. Run it in a sandbox with no production credentials, limited network and a throwaway filesystem. Then permit the open ended tool only there.
Steps to replace an open ended tool
- Log a month of shell or fetch usage and group the real commands.
- Find the top five repeated tasks. They are usually things like run tests, read a file, list tickets.
- Build or choose a narrow tool for each, with typed arguments.
- Move the agent to the narrow tools in a lower environment and compare results.
- Remove the general tool from production agents.
- Keep the sandboxed shell for development agents that truly need it.
Typed arguments help everything else
A narrow tool with typed, validated arguments is easy to constrain. The MCP specification requires servers to validate all tool inputs and expects tools to declare an input schema. A schema that says "folder name from this list" is a limit you can enforce, where "any string" is not.
The honest trade off
Narrow tools cost engineering time and sometimes block an unusual request. That friction is the point. If a request keeps hitting the wall, add a tool deliberately, with a review, rather than opening the shell.
Safeguard offers MCP Guardrail and agent identity for applying this kind of policy to agent tool calls, and you can run a free scan of your own repositories at gold.safeguard.sh/scan. Autonomous fix pull requests are off by default, and every category starts on Manual.
Quick check
Can I allow a shell if I filter dangerous commands?
Filters are easy to bypass. Use a sandbox with no sensitive access, and keep the shell out of production agents.
How many narrow tools is too many?
Group by job, not by endpoint. A short list of clear tools beats many near duplicates, which also confuse the model.
Sources
Last reviewed: 19 October 2026.
