What you will be able to do
- Audit a Managed Agents toolset and disable the tools a task doesn't need
- Build an allowlist-style toolset by turning every tool off by default
- Tell the difference between removing a tool and gating it with a permission policy
- Choose narrower tools over general-purpose ones such as computer use when they cover the task
1.Toolsets start fully enabled
Tool search deals with bloat by loading definitions later. The more basic question when reviewing an agent is whether it should have a given tool at all. That matters because bloat often comes from defaults rather than from anyone's decision.
In Claude Managed Agents, the built-in agent toolset (agent_toolset_20260401) contains bash, read, write, edit, glob, grep, web_fetch and web_search. When you include the toolset in an agent's configuration, all of them are enabled by default. An agent whose job is summarising documents in its sandbox gets a shell and open web access unless someone turns them off.
You can trim in either direction. To remove a few tools, add configs entries with enabled: false, for example turning off web_fetch and web_search. To grant only what the task needs, start from nothing: set default_config.enabled to false, then switch on individual tools.
{
"type": "agent_toolset_20260401",
"default_config": { "enabled": false },
"configs": [
{ "name": "bash", "enabled": true },
{ "name": "read", "enabled": true },
{ "name": "write", "enabled": true }
]
}Messages API client toolsets work the same way. The computer use and browser use toolsets accept per-member configs with an enabled flag. A disabled member is removed from the tools Claude sees. If Claude still names it, you return an error tool_result. You also can't disable every member; to do that, you omit the entry entirely.
The server denies it without evaluating any permission policy. The event carries evaluated_permission "deny" and no evaluation object, because the tool isn't enabled in the session. Removing the tool is final in a way that a permission setting is not.
2.Removing a tool is not the same as gating it
Managed Agents gives you a second setting on each tool, a permission policy: always_allow, always_ask or auto. It's tempting to treat always_ask as a way to reduce capability. It isn't. The documentation draws the line clearly: a permission policy decides *when* an enabled tool runs, and removing a tool means disabling it.
This matters for bloat because a gated tool is still enabled, so the model still sees it and can still choose it. If the tool has no place in the task, gating keeps both costs from the previous lesson and adds pauses for approval. Use disabling for tools the agent doesn't need. Use a policy for tools it needs but shouldn't run unsupervised.
MCP toolsets default to always_ask, so that new tools added to an MCP server can't execute in your application without approval. Custom tools, which your application executes, aren't governed by permission policies. Any trimming for them happens in your own code and tool list.
| Setting | What it controls | Effect on capability |
|---|---|---|
| enabled: false | Whether the tool exists for the agent | Removes the tool from the agent entirely |
| permission_policy (always_ask) | Whether an enabled tool's calls pause for approval | Tool stays available; calls wait for you |
| allowed_domains / blocked_domains | Which hosts web_search and web_fetch can reach | Tool stays available, limited to certain hosts |
| max_content_tokens | How much fetched page content enters context (web_fetch) | Tool stays available; output size is capped |
During a capability-bloat review of an agent configuration, which of the following actions would correctly reduce the agent's unnecessary tool surface? (Select all that apply.)(Select 3)
Correct answers: A, B, C — Disconnect MCP servers whose tools are never used by the agent's actual triage workflow, removing them from the session entirely.; Scope deny rules to specific MCP servers, e.g. disallowedTools: ["mcp__legacy__*"], rather than leaving all servers reachable.; Set disable-model-invocation: true on any skill that performs a side-effecting action the user should trigger manually.
- A. Correct. Disconnecting unused MCP servers removes their tool definitions from the session, which is an enforced reduction in the agent's actual capability surface.
- B. Correct. A deny rule scoped to a specific server's tools removes that server's tools from the request, directly narrowing what the agent can invoke.
- C. Correct. Hiding side-effecting skills from automatic model invocation ensures they only run on explicit user request, reducing unintended capability exposure.
- D. Incorrect. A CLAUDE.md note is guidance Claude may or may not follow; it does not remove any tool from the agent's available surface, so the underlying bloat remains.
- E. Incorrect. bypassPermissions removes approval friction but does not reduce which tools are available; it actually increases risk since any available tool, including unnecessary ones, runs without checks.
- F. Incorrect. An unanchored allowedTools: ["*"] entry is ignored with a startup warning and does not auto-approve anything, so this configuration does not behave as described and does not reduce bloat.
Sources3
3.Prefer narrow tools to general ones
The last kind of bloat is picking a tool that is more general than the task. The computer use toolset covers most other tools, because it drives a full desktop through screenshots and mouse and keyboard actions. It is also the slowest option, since Claude usually needs a fresh screenshot after each batch of actions. The documentation's advice is to prefer narrower tools when they cover the use case and to use computer use only when nothing else fits, such as legacy software with no API. If the whole task happens inside webpages, the browser use toolset fits better than computer use.
The same idea applies to the tools you keep. Pairing web search with web fetch lets Claude look at search snippets and fetch only the two or three pages that matter, instead of fetching everything upfront. On web_fetch, max_content_tokens caps how much of a fetched page enters the context.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Setting a tool's permission policy to always_ask removes that capability from the agent.Why is that wrong?
A permission policy only decides when an enabled tool runs. The tool stays available and Claude can still choose it. To take the capability away, disable the tool.
Covered in Removing a tool is not the same as gating it
2.Computer use can do what the other tools do, so enabling it on its own is the leanest configuration.Why is that wrong?
It is the most general option, and also the slowest. The guidance is to use narrower tools where they cover the task and to keep computer use for when nothing else fits.
Covered in Prefer narrow tools to general ones
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“All are enabled by default when you include the toolset in your agent configuration.”
↩︎ Toolsets start fully enabled“To start with everything off and enable only what you need, set default_config.enabled to false”
↩︎ Toolsets start fully enabled“Caps the amount of fetched page content included in the context.”
↩︎ Prefer narrow tools to general ones - 2.
“A disabled member is removed from the tools Claude sees. If Claude still names it, return an error tool_result.”
↩︎ Toolsets start fully enabled - 3.
“When the agent names a tool that is not enabled in the session, the server denies the call without evaluating a policy”
↩︎ Toolsets start fully enabled“This ensures that new tools added to an MCP server do not execute in your application without approval.”
↩︎ Removing a tool is not the same as gating it“Custom tools are executed by your application and controlled by you, so they are not governed by permission policies.”
↩︎ Removing a tool is not the same as gating it“Running sessions keep the toolset configuration they were created with.”
↩︎ Removing a tool is not the same as gating it“A permission policy controls when an enabled tool runs. To remove a tool from the agent entirely, disable it instead.”
↩︎ Exam trap 1 - 4.
“Computer use is the most general option and also the slowest”
↩︎ Prefer narrow tools to general ones“This avoids fetching everything upfront.”
↩︎ Prefer narrow tools to general ones“Prefer narrower tools when they cover your use case, and reach for computer use when nothing else fits.”
↩︎ Exam trap 2