Evaluate Tool/Agent Configuration for Capability Bloat

Claude Certified Architect – Professional (CCAR-P) Exam Guide

Domain 3: Integration — 19%

Exam objective: Evaluate tool/agent configuration for capability bloat.

---

1 What Is Capability Bloat?

Capability bloat occurs when an agent has more tools, actions, permissions, integrations, sub-agents, or overlapping capabilities than it actually needs to perform its assigned job.

Think of an agent’s configuration as its capability surface:

Agent
 │
 ├── Read Customer
 ├── Search Orders
 ├── Draft Response
 ├── Update Ticket
 ├── Issue Refund
 ├── Delete Account
 ├── Modify Subscription
 ├── Execute SQL
 ├── Send Email
 ├── Run Shell Command
 └── 25 more tools...

If this is a customer-service information assistant whose actual job is:

Read Customer
Search Orders
Draft Response

then most of the other capabilities are bloat.

The issue is not simply elegance.

Every unnecessary capability can introduce:

• additional security exposure,
• unnecessary authorization scope,
• more decisions for Claude to make,
• more tool definitions in context,
• more opportunities to choose the wrong tool,
• additional maintenance,
• greater testing requirements,
• increased blast radius if the agent is manipulated.

The unofficial workbook reinforces exactly this interpretation: keep the tool surface focused because schemas consume context and dilute selection, and remove capabilities the agent’s role does not require.

---

2 The Core CCAR-P Principle

For the exam, remember:

Give an agent the minimum set of capabilities necessary to perform its assigned responsibility.

This is closely related to least privilege, but capability bloat is slightly broader.

Least privilege asks:

What is this agent allowed to do?

Capability bloat asks:

Why does this agent have this capability at all?

Consider:

Customer Support Agent
├── get_ticket          ← required
├── search_orders       ← required
├── draft_reply         ← required
├── issue_refund        ← unused
└── delete_account      ← unused

The wrong approach is:

Keep everything
        ↓
Add confirmation prompts
        ↓
Add logging

The stronger design is:

Required?
   │
   ├── YES → expose tool with appropriate authorization
   │
   └── NO  → don't expose it

The official CCAR-P sample question uses almost exactly this scenario. A support agent can read tickets, draft replies, issue refunds, and delete accounts, while support employees only require the first two. The official correct answer is to remove the unnecessary refund and deletion capabilities rather than merely log or confirm their use.

⭐ Exam Rule

Removal > restriction > confirmation > logging

when the capability is genuinely unnecessary.

More precisely:

Capability not needed?
       ↓
REMOVE IT
       ↓
Capability legitimately needed sometimes?
       ↓
SCOPE / GATE IT
       ↓
Action is sensitive?
       ↓
AUTHORIZATION / APPROVAL
       ↓
Observe everything
       ↓
LOG / MONITOR

Logging is important, but it doesn’t convert unnecessary privilege into necessary privilege.

---

3 Why Capability Bloat Is Dangerous

There are six major consequences worth understanding for CCAR-P.

3.1 Security Attack Surface

Suppose an agent has 20 tools but needs only 5.

Every exposed capability creates another possible path through which:

• prompt injection,
• incorrect reasoning,
• compromised external content,
• configuration mistakes,
• malicious users

could produce an unwanted action.

Anthropic’s current security guidance specifically recommends limiting Claude’s access to sensitive data and actions, sandboxing tools where appropriate, and scoping permissions narrowly so that a successful prompt injection causes as little damage as possible.

Consider:

Malicious document
       ↓
Prompt injection succeeds
       ↓
Agent capabilities
       │
       ├── Search KB
       ├── Read Ticket
       ├── Draft Response
       ├── Delete User     ← unnecessary
       ├── Issue Refund    ← unnecessary
       └── Export Data     ← unnecessary

Even if the injection succeeds, the architecture determines the blast radius.

Better architecture

Malicious document
       ↓
Prompt injection succeeds
       ↓
Agent capabilities
       │
       ├── Search KB
       ├── Read Ticket
       └── Draft Response

The attacker now has much less useful capability to exploit.

That’s defense-in-depth.

---

4 Tool Selection Becomes Harder

Capability bloat also creates a reasoning problem.

Imagine these tools:

search_customer
find_customer
lookup_customer
get_customer
query_customer
retrieve_customer
customer_search

Technically they may all work.

But Claude now has to determine:

Which one should I use?

Anthropic’s current context-engineering guidance explicitly identifies bloated tool sets and ambiguous tool-choice points as a common failure mode and recommends curating a minimal viable tool set with minimal functional overlap.

Good configuration

get_customer(customer_id)
search_customers(query)

Clear distinction.

Bad configuration

lookup_customer(...)
query_customer(...)
get_user(...)
find_customer(...)
fetch_customer(...)
customer_details(...)
customer_search(...)

Overlapping tools make the model solve an unnecessary classification problem before solving the actual business problem.

---

5 Tool Definitions Consume Context

Tools are not free from a context perspective.

Each tool generally carries information such as:

Tool name
Description
Purpose
Input schema
Parameter descriptions
Required fields
Return structure

With:

5 tools

this may be trivial.

With:

500 tools

the definitions themselves can become substantial context.

Anthropic has documented this specifically for MCP: loading large numbers of tool definitions upfront can increase context consumption, response time, and cost. Anthropic describes environments with hundreds or thousands of tools where loading every definition into context becomes inefficient.

Therefore:

More Tools
   ↓
More Tool Definitions
   ↓
More Context Tokens
   ↓
More Processing
   ↓
Potentially Higher Cost + Latency

But there is another consequence:

More Definitions
       ↓
More Competing Signals
       ↓
Harder Tool Selection
       ↓
Potential Accuracy Decline

So capability bloat can affect:

Security + accuracy + latency + cost.

That cross-domain connection is very likely to matter in scenario questions.

---

6 Capability Bloat Is Broader Than Tool Count

This distinction is important.

An agent with 30 well-designed read-only discovery tools isn’t necessarily worse than an agent with four extremely powerful tools.

Consider:

Agent A

30 narrowly scoped read-only tools

versus:

Agent B

execute_sql(sql)
run_shell(command)
call_any_api(url, method, payload)
admin_action(action)

Agent B has only four tools.

But those four may represent an enormous capability surface.

Therefore:

Tool count is a signal, not the definition of capability bloat.

Evaluate:

1. Number of tools
2. Breadth of each tool
3. Overlap between tools
4. Privileges behind each tool
5. Relevance to the agent’s role
6. Whether capabilities are always exposed or discovered conditionally

---

7 Broad Tool vs Narrow Tool

Another likely exam trap is assuming:

“Fewer tools automatically means safer.”

Not necessarily.

Compare:

Design A

execute_command(command: string)

Claude could potentially execute:

read user
delete user
refund payment
change permissions
export data

Your application receives an opaque command.

Design B

get_customer(customer_id)
create_refund(order_id, amount)
close_ticket(ticket_id)

There are more tools, but their boundaries are explicit.

The workbook recommends promoting actions into dedicated tools when they need to be gated, audited, rendered, or parallelized, rather than hiding everything behind one opaque execution mechanism.

Exam principle

Don’t optimize:

number of tools

Optimize:

minimum clear capability surface required for the task.

---

8 Tool Overlap Is a Form of Capability Bloat

One subtle version of bloat is semantic overlap.

Suppose:

search_documents(query)
search_files(query)
find_knowledge(query)
knowledge_search(query)
retrieve_docs(query)

The agent’s reasoning becomes:

Need information
      ↓
Which search tool?
      ↓
Compare 5 similar descriptions
      ↓
Maybe pick wrong one

Anthropic emphasizes intentionally choosing which tools to implement, clearly defining their boundaries, and using clear descriptions/specifications.

Better

Design around meaningful capability boundaries:

search_policy_documents()
search_customer_records()
search_product_catalog()

or perhaps:

search_knowledge(source_type, query)

depending on authorization and operational requirements.

The correct choice depends on whether consolidating capabilities preserves:

• authorization boundaries,
• auditability,
• clarity,
• independent evolution,
• error handling.

---

9 Future Capabilities Are a Classic Exam Trap

The supplied practice exams contain a particularly revealing Domain 3 scenario:

An agent contains tools added for potential future use, but those tools are never actually used in production.

The intended reasoning is:

Evaluate and remove unused tool/agent capabilities because unnecessary capabilities increase attack surface and decision complexity.

This is very likely representative of the cognitive style you should expect.

Wrong architecture

"We might need it later."
        ↓
Configure tool now
        ↓
Give permission now
        ↓
Leave indefinitely

Better architecture

Need capability today?
      │
      ├── Yes → configure + evaluate + authorize
      │
      └── No  → don't expose
                    ↓
              Add later if required

This is essentially YAGNI applied to agent capabilities, combined with least privilege.

---

10 Static Exposure vs Progressive Discovery

This connects directly to another Domain 3 objective in the official blueprint:

Evaluate progressive discovery vs. monolithic context strategy.

Suppose your enterprise has:

Salesforce        120 tools
ServiceNow        90 tools
Google Drive      40 tools
Jira              60 tools
GitHub            80 tools
SAP              150 tools
─────────────────────────
Total             540 tools

Monolithic approach

Claude receives all 540 tool definitions
              ↓
         every request

Even for:

“Find my Jira ticket.”

That is wasteful.

Progressive approach

Request
   ↓
Identify likely capability/domain
   ↓
Discover Jira tools
   ↓
Load relevant subset
   ↓
Select required Jira action

This is progressive disclosure/discovery.

Anthropic’s current guidance describes just-in-time context loading and progressive disclosure, where agents incrementally discover relevant information rather than receiving everything upfront.

At very large MCP scale, Anthropic has likewise described loading only the tool interfaces needed for the task instead of all definitions upfront.

---

11 But Progressive Discovery Does Not Mean “Hide Security”

This is an important distinction.

Progressive discovery solves:

• context bloat,
• tool-selection complexity,
• unnecessary upfront schemas.

It does not replace authorization.

Bad architecture:

User
 ↓
Claude discovers hidden "delete_account"
 ↓
Calls it

Better:

User identity
      ↓
Authorization policy
      ↓
Permitted capability catalog
      ↓
Progressive discovery
      ↓
Claude sees only relevant AND permitted tools

Think of two separate filters:

AUTHORIZATION FILTER
"What MAY this user/agent do?"

          ↓

DISCOVERY FILTER
"What does this task NEED right now?"

Both matter.

---

12 Agent Bloat

The exam objective says:

tool/agent configuration

So don’t restrict your study to individual tools.

Capability bloat can also occur through unnecessary agents.

Consider:

Customer Support System
      ↓
Orchestrator
 ├── Ticket Agent
 ├── Customer Agent
 ├── Sentiment Agent
 ├── Policy Agent
 ├── Refund Agent
 ├── Escalation Agent
 ├── Email Agent
 ├── QA Agent
 ├── Summary Agent
 └── Supervisor Agent

Could this architecture work?

Yes.

Does it mean it is good?

No.

If the actual problem is:

Retrieve ticket
        ↓
Retrieve policy
        ↓
Draft response

a multi-agent system adds:

• coordination,
• additional model calls,
• failure points,
• latency,
• context boundaries,
• monitoring complexity,
• potentially duplicated capabilities.

Anthropic recommends starting with the simplest architecture that satisfies the requirement and adding agentic complexity only where simpler approaches fall short.

Exam trap

“More specialized agents = better architecture.”

False.

---

13 Capability Isolation Across Agents

However, multiple agents can sometimes reduce capability bloat.

Consider one universal agent:

Universal Support Agent
 ├── search_KB
 ├── read_customer
 ├── update_customer
 ├── refund_payment
 ├── cancel_account
 ├── create_invoice
 ├── modify_contract
 ├── query_database
 └── ...

Instead:

                    Router
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
     Knowledge      Billing      Account
      Agent          Agent        Agent
       │              │            │
  search_KB       read_bill    read_account
  read_policy     refund*      update_profile

The *refund action could require separate authorization or approval.

Now each agent gets:

the capabilities appropriate to its responsibility.

That can improve:

• security isolation,
• tool-selection accuracy,
• context efficiency,
• ownership.

But don’t automatically introduce multi-agent architecture merely to split tools. The extra orchestration must provide enough value to justify its complexity.

---

14 Role-Based Capability Surfaces

A very strong enterprise design is to construct the tool surface around the role.

For example:

Customer Support Tier 1

✓ Read ticket
✓ Read customer
✓ Search KB
✓ Draft response

✗ Issue refund
✗ Modify contract
✗ Delete account

Customer Support Tier 2

✓ Read ticket
✓ Read customer
✓ Search KB
✓ Draft response
✓ Request refund

✗ Delete account

Account Administrator

✓ Read account
✓ Modify account
✓ Close account

The architecture becomes:

User Identity
      ↓
Role / Entitlements
      ↓
Permitted Capabilities
      ↓
Task-Relevant Capabilities
      ↓
Claude

That is considerably stronger than:

Give Claude everything
      ↓
Tell it what not to use

---

15 Prompt Instruction Is Not Capability Removal

A common distractor will look something like:

Keep the dangerous tool but add this to the system prompt:

“Never use delete_account unless absolutely necessary.”

That is weaker than removing the capability.

Why?

Because:

Tool exists
   ↓
Model can invoke it

and instructions remain model-interpreted behavior.

For something the agent never needs, the best control is:

Tool does not exist
in that agent's capability surface.

Anthropic’s security guidance similarly emphasizes narrow access to sensitive actions rather than relying solely on model instructions.

---

16 Logging Is Not a Substitute for Least Privilege

Another classic exam distractor:

Agent has delete_account.
         ↓
Log every use.

Logging tells you:

Something bad happened.

Least privilege can ensure:

This agent couldn’t do that in the first place.

Compare:

Control	Purpose
Remove capability	Preventive
Scope permissions	Preventive
Authorization gate	Preventive
Human approval	Preventive/compensating
Logging	Detective
Alerting	Detective

If the capability isn’t required:

prefer preventive elimination.

The official sample question explicitly differentiates removing unnecessary tools from logging and confirmation controls.

---

17 Capability Bloat Can Be Hidden Behind Credentials

Sometimes the tool configuration looks reasonable:

get_customer()
update_ticket()

But both use:

SERVICE_ADMIN_API_KEY

with access to every customer and operation.

Now the declared capability is narrow, but the underlying authorization capability is broad.

So evaluate:

Tool surface
     +
Credential permissions
     +
Backend authorization

The supplied practice exams specifically test a related scenario: a shared credential granting full account access to every request. The architectural problem is that this broad authorization violates least privilege and enlarges the blast radius.

Exam mindset

Don’t stop at:

“What tools are exposed?”

Also ask:

“What can those tools actually do with the identity/credential behind them?“

---

18 The Capability Bloat Evaluation Framework

For CCAR-P, use this 7-step method whenever the question asks you to review an agent/tool configuration.

Step 1 — Define the Agent’s Responsibility

Ask:

What exactly is this agent supposed to accomplish?

Example:

Agent responsibility:
Help Tier-1 support representatives answer customer questions.

Not:

"Handle customer operations."

Clear responsibility creates clear capability boundaries.

Step 2 — Inventory the Capabilities

Create a simple list:

Capability	Used?	Required?	Risk
Search KB	Yes	Yes	Low
Read ticket	Yes	Yes	Low
Draft reply	Yes	Yes	Low
Issue refund	No	No	High
Delete account	No	No	Critical
Export customer data	No	No	High

Now capability bloat becomes visible.

Step 3 — Classify Each Capability

A useful model:

REQUIRED
Necessary for the normal responsibility

CONDITIONAL
Needed only for defined scenarios/roles

UNUSED
Configured but not used

DUPLICATE
Overlaps another capability

SPECULATIVE
Added "for the future"

Then:

Required     → Keep
Conditional  → Gate / expose dynamically
Unused       → Remove
Duplicate    → Consolidate/redefine
Speculative  → Remove until requirement exists

Step 4 — Examine Privilege

For every retained tool ask:

What data can it read?
What data can it write?
Can it delete?
Can it transfer money?
Can it communicate externally?
Can it execute arbitrary code?
Whose identity does it use?

A useful risk hierarchy:

Read-only lookup
      ↓
Write reversible data
      ↓
External communication
      ↓
Financial transaction
      ↓
Delete / destructive operation
      ↓
Arbitrary code / broad admin

The higher the capability, the stronger your reason and controls must be.

Step 5 — Examine Tool Selection Ambiguity

Ask:

Are there two or more tools Claude could reasonably choose for the same task?

Example:

search_orders
find_order
lookup_order
query_order

If yes, consider:

• removing duplicates,
• clarifying scopes,
• improving naming,
• improving descriptions,
• separating by genuine semantic boundaries.

Anthropic notes that tool descriptions and specifications materially influence how agents select and use tools; descriptions should clearly communicate expected usage and inputs.

Step 6 — Measure Context Cost

Don’t merely count tools.

Measure:

Tool-definition tokens
      +
tool-result tokens
      +
system instructions
      +
retrieved context
      +
conversation history

For a large enterprise integration library, consider:

All tools upfront
        ↓
     versus
        ↓
Progressive discovery

Anthropic’s MCP work demonstrates why this becomes significant at hundreds or thousands of tools: tool definitions themselves can consume large amounts of context.

Step 7 — Evaluate Before and After

After pruning capability bloat, test whether the change actually improves the system.

Measure:

• task success,
• correct tool selection,
• unnecessary tool-call rate,
• failed tool calls,
• latency,
• tokens,
• cost,
• security violations,
• escalation rate.

This is important because:

“fewer tools” is not itself the success metric.

The success metric is:

Does the reduced capability surface perform the required task more reliably and safely?

Anthropic’s tool-design guidance recommends developing comprehensive evaluations of tools and iterating based on agent performance rather than designing purely from intuition.

---

19 A Practical Decision Tree

Memorize this for the exam:

Does the agent need this capability?
            │
        ┌───┴───┐
       NO      YES
       │         │
    REMOVE    Does every request need it?
                 │
             ┌───┴───┐
            NO      YES
            │         │
       Discover/Gate  Keep available
            │         │
            └────┬────┘
                 ↓
        Is it sensitive/destructive?
                 │
             ┌───┴───┐
            YES      NO
             │        │
       Narrow scope   Normal
       Authorization  invocation
       / Approval
             │
             ↓
         Audit/Monitor

---

20 Example 1 — Customer Support Agent

Initial design

Customer Support Agent
│
├── get_customer
├── get_order
├── search_policy
├── draft_reply
├── refund_order
├── cancel_order
├── delete_customer
├── export_customer_data
└── change_subscription

Requirement:

Tier-1 agents answer status and policy questions and draft customer responses.

Analysis

Required:

get_customer
get_order
search_policy
draft_reply

Not required:

refund_order
cancel_order
delete_customer
export_customer_data
change_subscription

Correct redesign

Tier-1 Support Agent
│
├── get_customer
├── get_order
├── search_policy
└── draft_reply

For refund workflows:

Tier-1 Agent
     ↓
Escalate Refund Request
     ↓
Authorized Refund Workflow/Agent
     ↓
Authorization
     ↓
refund_order

That is the professional architecture answer.

---

21 Example 2 — Enterprise Research Agent

Suppose there are:

Google Drive   50 tools
SharePoint     80 tools
Salesforce    100 tools
GitHub         60 tools
Jira           70 tools
ServiceNow     90 tools

Total:

450 tools

Question:

Should all tool definitions be supplied to Claude on every request?

Usually not.

Better:

User asks:
"Find architecture decisions related to Project Orion."
                ↓
Capability discovery
                ↓
Relevant sources identified:
Drive + SharePoint
                ↓
Relevant search tools loaded
                ↓
Documents retrieved

This is one reason the official blueprint separately tests progressive discovery vs. monolithic context.

---

22 Example 3 — Dangerous “Universal” Tool

Design:

execute_api(
   endpoint,
   method,
   payload
)

It can invoke:

GET customer
POST refund
DELETE user
PATCH permissions
POST transfer

At first glance:

“Great — one tool instead of 20.”

But the capability boundary is enormous.

Better options might expose:

get_customer()
get_order()
draft_case_update()
request_refund()

with different authorization policies.

CCAR-P lesson

Tool minimization does not mean hiding many privileged operations behind one unrestricted super-tool.

Capability surface matters more than raw count.

---

23 Indicators of Capability Bloat

Watch for these phrases in exam stems:

🚩 “Added for future use”

Likely remove it.

🚩 “Agent has access to every available tool”

Question the design.

🚩 “The same credential grants full access”

Look for least-privilege failure.

🚩 “Several tools perform similar operations”

Look for selection ambiguity / redundant capabilities.

🚩 “All MCP tools are loaded at startup”

Consider progressive discovery/context overhead.

🚩 “The agent never invokes these tools”

Remove/prune.

🚩 “Keep dangerous capabilities but add logging”

Logging does not eliminate exposure.

🚩 “Keep tools but tell Claude not to use them”

Advisory behavior is weaker than architectural removal.

🚩 “One agent can invoke every other agent”

Evaluate whether agent-to-agent capability is unnecessarily broad.

🚩 “Universal administrator tool”

Investigate actual privilege scope.

---

24 Common Exam Traps

Trap 1 — “More capabilities make the agent more flexible”

Wrong mindset.

Flexibility that the requirement doesn’t need creates complexity and exposure.

Trap 2 — “Keep unused tools because they may be useful later”

Wrong.

Add them when a validated use case exists.

Trap 3 — “Logging solves the risk”

Wrong.

Logging = observe
Least privilege = prevent

Trap 4 — “Confirmation prompts solve privilege”

Not if the capability should never have existed for that role.

Trap 5 — “A bigger model will choose tools correctly”

A more capable model doesn’t make an unnecessarily broad capability surface architecturally sound.

Trap 6 — “Tool count alone defines bloat”

Wrong.

Four unrestricted super-tools can be riskier than twenty narrow tools.

Trap 7 — “Progressive discovery replaces authorization”

Wrong.

Discovery decides what is relevant.

Authorization decides what is allowed.

Trap 8 — “Remove every tool used infrequently”

Wrong.

Usage frequency alone isn’t enough.

An emergency escalation capability could be necessary even if invoked 0.1% of the time.

Ask:

Is it required, not merely frequent?

---

25 Capability Bloat vs Related Concepts

Concept	Main question
Capability bloat	Does this agent have more capability than it needs?
Least privilege	Does it have more permission than necessary?
Tool ambiguity	Can Claude clearly identify the appropriate tool?
Context bloat	Is too much information loaded into context?
Architectural bloat	Are too many workflows/agents/components being used?
Progressive discovery	Can relevant capabilities/context be loaded only when needed?
Tool authorization	Is the requested action allowed for this identity?
Observability	Can we determine what the agent actually did?

They are related but not interchangeable.

---

26 High-Yield CCAR-P Mental Model

For every tool/agent configuration question, ask these five questions:

1 Does the role need this capability?

If no → remove it.

2 Does every task need this capability?

If no → consider conditional/progressive exposure.

3 Does it overlap another tool?

If yes → clarify or consolidate.

4 What happens if Claude invokes it incorrectly?

High impact → stronger authorization, gating or human approval.

5 What does exposing it cost?

Think:

Security
Context
Accuracy
Latency
Cost
Maintenance

A good CCAR-P architect evaluates all six.

---

27 Exam-Focused Comparison

Configuration	Assessment
40 tools, all required and clearly differentiated	May be acceptable
12 tools, 7 never used	Capability bloat
6 tools, 4 perform almost the same action	Likely bloat/ambiguity
4 unrestricted admin tools	Very high-risk capability bloat
100 enterprise tools discovered progressively	Potentially good design
100 enterprise tools loaded for every task	Context/tool-selection concern
Sensitive tool available but “Claude is instructed not to use it”	Weak
Sensitive tool omitted from unauthorized role	Strong
Refund capability behind explicit authorization	Appropriate if required
Unused refund capability plus confirmation prompt	Still unnecessarily exposed

---

28 Two Practical Exercises

You asked to replace the linked guide’s “Build Exercise” with exercises more directly useful for CCAR-P preparation.

Exercise 1 — Capability Surface Audit

You inherit this customer-service agent:

Tools:
1. search_customer
2. get_order
3. search_KB
4. draft_reply
5. send_reply
6. issue_refund
7. cancel_order
8. delete_customer
9. export_customer
10. execute_sql
11. update_subscription
12. generate_discount

Business requirement:

Tier-1 support representatives use Claude to investigate customer questions and draft responses. They may not make financial, destructive, or customer-data-management changes.

Your task

Classify every tool as:

KEEP
REMOVE
GATE
REDESIGN

Then answer:

1. What is the minimum viable capability surface?
2. Which tools create the largest blast radius?
3. Are any tools too broad?
4. What capabilities should live in a separate privileged workflow?
5. What should be authorized in code rather than by prompt?
6. What metrics would prove the redesign helped?

Suggested answer

Core agent:

search_customer
get_order
search_KB
draft_reply

Possibly:

send_reply → gated depending on business policy

Remove:

issue_refund
cancel_order
delete_customer
export_customer
execute_sql
update_subscription
generate_discount

unless separate validated use cases require them.

The most suspicious capability is:

execute_sql

because the apparent single tool may expose a very broad underlying capability.

Exercise 2 — 300-Tool MCP Architecture

Your enterprise assistant connects to:

Jira          40 tools
GitHub        50
Salesforce    70
ServiceNow    50
Google Drive  35
SharePoint    55
────────────────
Total        300

Users normally need only 3–8 tools for a particular request.

Design the capability-loading strategy.

Expected architecture

User identity
      ↓
Authorization / entitlement filtering
      ↓
Capability catalog
      ↓
Progressive discovery
      ↓
Task-relevant server/domain
      ↓
Relevant subset of tools
      ↓
Claude selects tool
      ↓
Execute under narrow permissions
      ↓
Audit

Explain why this is superior to:

All 300 tool definitions
        ↓
every request

Your answer should cover:

• context consumption,
• tool-selection ambiguity,
• latency/cost,
• least privilege,
• maintainability,
• evaluation.

Anthropic’s current guidance on progressive context discovery and large MCP tool inventories strongly supports this general architecture.

---

29 Five CCAR-P Style Practice Questions

These are new study questions, not live Anthropic exam questions.

Question 1 — Unused Capabilities

A retail company’s returns assistant is configured with the following tools:

• retrieve_order
• retrieve_return_policy
• draft_response
• issue_refund
• delete_customer
• modify_loyalty_balance

Production telemetry over three months shows that the assistant only retrieves orders/policies and drafts responses. Refunds are handled by a separate workflow, and the remaining tools have never been used.

Which change BEST addresses capability bloat?

A. Retain all tools but improve their descriptions.

B. Retain them because future business requirements may eventually need them.

C. Remove capabilities not required by this agent’s current responsibility and add them later through controlled change if requirements evolve.

D. Keep all tools but log calls to the sensitive ones.

✅ Correct Answer: C

Capability bloat means exposing capability without corresponding current value. Removing unused tools reduces attack surface and tool-choice complexity.

A might improve selection but doesn’t address unnecessary capability.

B is speculative privilege.

D provides detection after the capability has already been exposed.

This closely follows the reasoning of the official CCAR-P least-privilege sample item.

Exam clue

Look for:

“never used” + “future use”

→ prune/remove.

Question 2 — Broad Tool vs Tool Count

An architect wants to reduce a finance agent from 15 tools to one:

execute_finance_operation(operation_name, parameters)

The generic tool can query balances, modify payment details, issue refunds, cancel invoices, and transfer funds.

What is the PRIMARY concern?

A. Agents perform better when they have exactly 15 tools.

B. Tool count decreased, but the agent’s effective capability and authorization surface may have become broader and less governable.

C. Claude requires separate MCP servers for every financial action.

D. Generic tools cannot accept structured input.

✅ Correct Answer: B

Capability surface ≠ tool count.

A single generic tool can encapsulate enormous privilege.

Dedicated operations may be preferable when different actions require:

• different authorization,
• audit rules,
• approval,
• risk controls.

Exam clue

Don’t simply choose:

“fewest tools.”

Choose:

smallest well-bounded capability surface.

Question 3 — Progressive Discovery

A large enterprise assistant can access 600 tools across multiple MCP servers. For each user request, the existing application loads all 600 tool definitions into Claude’s context, although typical tasks require fewer than ten.

Which architectural improvement BEST addresses capability/context bloat while retaining enterprise functionality?

A. Replace Claude with a larger-context model and continue loading all tools.

B. Remove every tool except the ten most frequently used.

C. Introduce progressive capability discovery so the system exposes only task-relevant and authorized tool definitions when required.

D. Keep all 600 tools and shorten their names.

✅ Correct Answer: C

Progressive discovery preserves the broader enterprise capability catalog while avoiding unnecessary upfront context.

Anthropic’s current guidance describes progressively loading relevant context and, for large MCP tool ecosystems, loading only interfaces needed for the task.

B is too simplistic because infrequent tools may still be legitimate.

A treats a context-management/design problem by merely increasing capacity.

D offers negligible improvement.

Exam clue

Large tool catalog
+
small per-task subset

→ think progressive discovery.

Question 4 — Multiple Response

Select TWO.

A healthcare administrative agent must read appointment information, search policies, and draft messages. It is also configured with patient-record deletion and billing-adjustment tools that this role never legitimately uses.

Which TWO changes provide the strongest reduction in risk from capability bloat?

A. Remove the deletion and billing tools from this agent’s exposed capability surface.

B. Add instructions telling Claude to avoid those tools unless absolutely necessary.

C. Add additional logs around deletion and billing.

D. Ensure the remaining tools operate with narrowly scoped authorization appropriate to the requesting identity.

E. Upgrade to a more capable Claude model to reduce incorrect tool calls.

✅ Correct Answers: A and D

A addresses capability bloat directly.

D ensures retained capabilities don’t hide unnecessarily broad authorization.

Anthropic recommends narrow permissions for sensitive tools and data so that compromised or manipulated agent behavior has limited effect.

B is advisory.

C is detective rather than preventive.

E doesn’t repair an authorization architecture.

Exam clue

If the options include:

remove unnecessary capability
+
scope remaining permissions

that pair is usually much stronger than:

prompt + monitor

Question 5 — Tool Selection Ambiguity

A reporting agent has these five tools:

search_reports
find_reports
query_reports
retrieve_reports
lookup_reports

All query substantially the same repository with slightly different parameter formats. Evaluation shows frequent tool-selection errors.

What should the architect do FIRST?

A. Increase the number of few-shot examples demonstrating each tool.

B. Use a larger model.

C. Evaluate whether these capabilities should be consolidated or given non-overlapping boundaries and clearer descriptions.

D. Add retries whenever the wrong tool is chosen.

✅ Correct Answer: C

The architecture is forcing Claude to distinguish unnecessarily overlapping capabilities.

Anthropic identifies ambiguous, overlapping tool sets as a common design problem and recommends clearly bounded tools with well-engineered descriptions/specifications.

A may teach Claude to compensate for poor design.

B is an expensive workaround.

D treats the symptom rather than the cause.

Exam clue

Similar names + overlapping functionality + wrong selection

→ fix the capability design first.

---

30 Rapid Revision Sheet

If you only remember one page before the exam, remember this:

Capability bloat means:

The agent has more capability than its responsibility requires.

Sources of bloat

Unused tools
Speculative "future" tools
Duplicate/overlapping tools
Overly broad tools
Over-privileged credentials
Unrestricted agent-to-agent access
Too many capabilities loaded upfront
Unnecessary specialized agents

Consequences

Attack surface ↑
Blast radius ↑
Tool ambiguity ↑
Context usage ↑
Latency/cost ↑
Testing burden ↑
Maintenance ↑

Correct responses

REMOVE unnecessary capabilities

SCOPE retained capabilities

GATE conditional/high-risk capabilities

SEPARATE responsibilities where useful

DISCOVER large capability sets progressively

CLARIFY overlapping tool boundaries

EVALUATE tool selection and task success

MONITOR what remains

Don’t confuse controls

REMOVE      → eliminates capability
AUTHORIZE   → determines whether action is permitted
APPROVE     → human/system gate before sensitive action
PROMPT      → guides model behavior
LOG         → records what happened
MONITOR     → detects unusual behavior

They solve different problems.

---

31 The One Sentence to Memorize

Expose only the smallest clear set of tools and agent capabilities required for the current role and task; remove unused or speculative capabilities, narrowly authorize sensitive operations, and progressively discover larger tool sets when exposing everything upfront would add security, selection, or context overhead.

That sentence captures most of what a CCAR-P architect needs to recognize for this objective.

---

32 How I Expect CCAR-P to Test This

Based on the official objective, official sample item, practitioner material, and both provided practice exams, I would prioritize the following scenario patterns:

Probability / Importance	Scenario
⭐⭐⭐⭐⭐	Agent has unused sensitive tools → remove them
⭐⭐⭐⭐⭐	Logging/confirmation vs removal → removal wins if capability isn’t needed
⭐⭐⭐⭐	Shared/full-access credential → scope authorization
⭐⭐⭐⭐	Many overlapping tools → reduce ambiguity
⭐⭐⭐⭐	Huge MCP tool inventory → progressive discovery
⭐⭐⭐	Universal agent with all tools → role/task-specific surface
⭐⭐⭐	One generic super-tool vs explicit capabilities → examine effective privilege, not count
⭐⭐⭐	Unrestricted agent-to-agent invocation → constrain capability boundaries
⭐⭐⭐	Larger model offered as solution → likely distractor when configuration is the actual problem

The biggest mistake would be memorizing:

“fewer tools = good.”

The higher-level architectural rule is:

No unnecessary capability, no unnecessary privilege, no unnecessary choice.

That is the reasoning likely to transfer best across CCAR-P scenario questions.