What you need to know
Capability bloat is what happens when an agent accumulates tools, connected servers and permissions beyond what its job requires. It usually arrives gradually: someone connects a whole MCP server when one tool was needed, a "just in case" admin tool is left in, every team adds its favourite integration.
Why it hurts
| Cost | What happens |
|---|---|
| Accuracy | With many similar tools, the model picks the wrong one or calls several where one would do |
| Tokens and latency | Every tool definition is sent on every call; dozens of tools can add thousands of tokens per request |
| Security | Every tool is something an injected instruction or a mistake can use |
| Operations | More integrations to monitor, version and debug |
How to cut it back
- Start from the task, not the catalogue. List the actions the job actually needs. Everything else goes.
- Prefer a few purposeful tools over many thin ones. One
get_customer_summarythat returns the fields the task needs beats five low-level endpoints the model must chain together. - Give every tool a clear, distinct description: what it does, when to use it, what its parameters mean, and how it differs from similar tools. Overlapping descriptions cause wrong choices.
- Return only what the task needs. Tool responses go into the context too. Return the relevant fields, paginate or summarize large results, and give helpful errors instead of stack traces.
- Split by role. If two parts of a job need different tools, give them to different agents or subagents, each with its own small set, rather than one agent with the union.
- Load on demand when the set is genuinely large. When an agent really does need access to hundreds of tools, a tool search capability lets it discover and load only the relevant ones (lesson 3.4).
Configuration, not only tools
Bloat also hides in configuration: broad permission modes, write access to whole file systems, network access the task does not need, many MCP servers enabled globally instead of per project. The same discipline applies: the narrowest configuration that lets the task succeed.
In the exam
Look for symptoms: the agent calls the wrong tool, requests are expensive before the user has typed anything, or a tool exists that the task never needs (especially a destructive one). The best answer trims or consolidates tools, sharpens descriptions, splits roles, or loads tools on demand. Distractors add more instructions about tool choice, move to a bigger model, or keep dangerous tools behind a prompt warning.
Check your understanding
An agent often calls search_tickets when get_ticket was the right tool. Both descriptions say "retrieves ticket information". What should be done first?
Show answer
Answer: D. Overlapping descriptions cause wrong choices. Making each tool's purpose and use case distinct fixes the cause; the other options work around it.
An internal agent's requests carry 12,000 tokens of tool definitions, yet the agent uses only 7 of its 45 tools in practice. What is the best change?
Show answer
Answer: C. Unused tools cost tokens, confuse selection and widen the attack surface. Caching lowers the price of the bloat but keeps every other cost.
A reporting agent needs to read sales data and produce charts. Which TWO tools should it not have?
Show answer
Answer: B, C. The task needs to read data and render charts. Deletion and outbound email serve no step of the task and turn a mistake or an injected instruction into real damage.
Apply it: Trim Larkfield's claims agent
Larkfield's IT team connected the intake assistant to ClaimsCore's full MCP server, which exposes 38 tools: create, read, update and close claims; add notes; upload documents; approve payments; reopen claims; bulk export; manage users; and more. The assistant's job is intake as designed in lesson 1.2.
- List the tools intake actually needs, mapped to the steps of the intake design.
- Name the tools that must go, and why each is dangerous or wasteful.
- Decide how the trimmed set is delivered: the full server with restrictions, or a purpose-built set.
Done when: the intake assistant physically cannot approve a payment. - Say what you would measure to show the change helped.
Show model answer
1. Needed tools
| Intake step | Tool |
|---|---|
| Check the policy | get_policy_status(policy_number, date_of_loss) (Policy Admin) |
| Create the claim | create_claim(fields) with schema validation |
| Attach documents | attach_document(claim_id, document_ref) |
| Note what is missing | add_intake_note(claim_id, text) |
Four tools, all scoped to intake.
2. Tools to remove. Approve payments and close claims (consequential decisions reserved for adjusters), update and reopen claims (intake only creates), bulk export and user management (no intake purpose and high exposure), and every read tool that returns other claims (intake never needs another customer's claim).
3. Delivery. A purpose-built intake toolset, either a small intake MCP server or tools defined directly in the intake service, using credentials that can only create claims and add notes. Hiding tools from a full server is weaker: the credentials would still be able to approve payments.
4. Measures. Tool-choice accuracy on the intake evaluation set, input tokens per request (tool definitions shrink from 38 to 4), and a security review confirming the credentials cannot call payment or export endpoints.