Five real, previously unpublished CCA-F practice questions for Tool Design & MCP Integration (18% of the exam). Try to answer each one yourself before revealing the explanation — that's how you actually find the gaps in your understanding.
Practice the full domain-filtered set on AICert Study →
Question 1
When designing the description for the process_refund MCP tool used by the customer support agent, which of the following pieces of information is MOST important to include?
- A. When the tool should be used, when it should NOT be used, parameter semantics, and refund policy boundaries
- B. The exact internal SQL query the tool runs against the orders database
- C. A short phrase such as 'refunds orders' to keep the description compact and reduce tokens
- D. The version number and release notes of the backend refund microservice
Show answer & explanation
Correct answer: A
Anthropic's tool-use guidance is explicit: descriptions should cover what the tool does, when to use and not use it, parameter meanings, and important caveats (such as policy limits). This is what the model relies on to select the right tool and to recognize cases that should escalate.
- The exact internal SQL query is incorrect. Implementation details are noise for the model - they consume context without helping selection or argument construction.
- A short phrase like 'refunds orders' is incorrect. Minimal descriptions are the canonical anti-pattern; Anthropic cites a single short sentence as the poor-description example and recommends 3-4+ sentences instead.
- Version number and release notes is incorrect. Release metadata does not help the model decide when the tool is appropriate and wastes context.
Share this question on LinkedIn →
Question 2
The MCP server backing process_refund currently returns a single text content block 'Operation failed' for every error (gateway timeout, invalid order_id, refund over policy limit). Evals show the agent gives up or retries blindly. Which improvement BEST helps the agent recover correctly?
- A. Return isError: true with structured content including errorCategory (transient | validation | business | permission), isRetryable boolean, and a human-readable description
- B. Raise a JSON-RPC -32000 protocol error so the MCP client surfaces the exception to the user
- C. Return isError: false but include the error text in a system prompt that the agent reads on the next turn
- D. Always return the same generic message but log the real cause server-side for the on-call engineer to triage
Show answer & explanation
Correct answer: A
MCP's isError: true is the protocol-level signal that the tool execution failed and should be passed back to the model so it can reason about recovery. Pairing it with errorCategory, isRetryable, and a description lets the agent decide: retry on transient, fix arguments on validation, escalate on business, ask for credentials on permission.
- JSON-RPC -32000 protocol error is incorrect. Protocol errors are for unknown tools, invalid arguments, or server crashes - not for normal tool execution failures. Throwing protocol errors hides the cause from the model.
- isError: false with a system prompt is incorrect. The agent cannot mutate the system prompt mid-conversation, and isError: false would make the failure indistinguishable from success.
- Always return a generic message is incorrect. This is precisely the broken behavior the question describes - uniform messages prevent the agent from choosing an appropriate recovery strategy.
Share this question on LinkedIn →
Question 3
Which of the following MCP error scenarios should be modeled with isRetryable: true?
- A. Upstream payment gateway returned a 503 timeout after 2 seconds
- B. The order_id format is invalid (expected 'ORD-' prefix, got 'X-12345')
- C. The refund amount exceeds the customer's lifetime refund policy limit
- D. The agent's API key lacks the 'refunds:write' scope
Show answer & explanation
Correct answer: A
Transient errors - gateway timeouts, 5xx, brief unavailability - are the canonical retryable category. The agent (or a wrapper) can back off and retry without changing inputs or asking the user.
- Invalid order_id format is incorrect. Validation errors are not retryable because the same input will fail again; the agent must correct the argument or ask the user for clarification.
- Refund exceeds policy limit is incorrect. Business/policy violations are not retryable; the agent must escalate or change the request semantics, not retry.
- Missing API scope is incorrect. Permission errors are not retryable from the agent's perspective; they require a credential or policy change out-of-band.
Share this question on LinkedIn →
Question 4
A developer productivity agent has access to Read, Write, Edit, Bash, Grep, and Glob plus 12 MCP-provided tools. The team needs to find every file that imports the deprecated module 'legacy_auth' across a 50k-file monorepo. Which built-in tool is the correct first choice?
- A. Grep with pattern 'from legacy_auth' or 'import legacy_auth' across the repo
- B. Glob with pattern '**/legacy_auth*' to find files by name
- C. Read every file in the repo and check the imports manually in context
- D. Bash with 'find . -name "*.py" | xargs cat | grep legacy_auth'
Show answer & explanation
Correct answer: A
Grep is the built-in content search tool (backed by ripgrep) and is the right tool for finding text patterns like import statements across many files. It returns matched paths efficiently without loading file contents into the agent's context.
- Glob with '/legacy_auth*'** is incorrect. Glob matches file paths, not file contents. It would find a file literally named legacy_auth.py but miss every other file that imports it.
- Read every file is incorrect. Reading 50k files would blow the context window and is precisely what Grep exists to avoid.
- Bash find | xargs cat | grep is incorrect. Claude Code guidance is explicit that built-in tools should be preferred over shelling out: Grep is faster, respects permission caching, and avoids loading concatenated file contents through the shell pipeline.
Share this question on LinkedIn →
Question 5
A research coordinator agent currently exposes 18 tools to a single research subagent: web search, scholar search, two database query tools, PDF parsing, OCR, citation formatter, plus 11 internal lookup tools. Evals show the subagent picks the wrong tool ~30% of the time. According to Anthropic and MCP community guidance, what is the recommended first fix?
- A. Split the work into specialized subagents, each scoped to the 4-5 tools needed for its role
- B. Switch to tool_choice 'any' so the model is always forced to pick something
- C. Add more tools so the agent has more options to triangulate the right answer
- D. Disable all but one tool per turn and let the user select which one is active
Show answer & explanation
Correct answer: A
Anthropic and MCP community research show that tool selection reliability degrades sharply as the tool surface grows; agents perform best when scoped to the small set (typically 4-5) of tools needed for their specialization. The orchestrator-subagent pattern is the canonical fix: split work so each subagent sees only its relevant tools.
- tool_choice 'any' is incorrect. 'any' forces a tool call but does NOT improve which tool is picked among 18. It removes the option of replying with text, but does not solve the overload problem.
- Add more tools is incorrect. Adding tools makes the problem worse: more candidates, more confusion, more context burned.
- Let the user select per turn is incorrect. This defeats the purpose of an autonomous agent and is not a recognized pattern in Anthropic guidance; the agent should be designed to pick correctly from a focused toolset.
Share this question on LinkedIn →
Want more? Our free bank has hundreds of Tool Design & MCP Integration questions. Practice them all →