Free CCAR-F Tool Design & MCP Integration Practice Questions
The Tool Design & MCP Integration domain makes up 18% of the Anthropic CCAR-F exam. Practice free questions covering tool schemas and descriptions, MCP servers and clients, resources vs tools, transports, and tool-use error handling — each with the correct answer and a detailed explanation.
CCAR-F Tool Design & MCP Integration Sample Questions with Answers
Sample Question 1 — Tool Design & MCP Integration
A customer-support agent has three tools named customer_lookup, account_lookup, and profile_lookup. Their descriptions all say, "Find customer information," but each tool queries a different system and accepts a different identifier. Production traces show that Claude frequently selects the wrong tool. What is the BEST architectural change?
- A. Combine the tools into one interface with optional parameters for every supported identifier and backend.
- B. Rename and document each tool with its purpose, accepted identifier, output, boundaries, and selection examples. (Correct answer)
- C. Keep the interfaces unchanged and instruct Claude to retry another tool whenever no customer is returned.
- D. Provide all three tools through separate MCP servers while retaining their current names and descriptions.
Correct answer: B
Explanation: Correct answer (B): The tools need distinct semantic boundaries and descriptions that state their purpose, inputs, outputs, and appropriate selection conditions. Examples can further clarify similar cases. Clear interfaces reduce model selection ambiguity, which matters in production because choosing the wrong customer system can cause incorrect conclusions or actions.
Why the other options are wrong:
- Option A: Combining distinct backends and identifier types behind many optional parameters would preserve or increase ambiguity rather than create clear boundaries.
- Option C: An empty result can be valid, so speculative retries against unrelated systems are unsafe and do not resolve the underlying interface ambiguity.
- Option D: Separate servers may support security or ownership boundaries, but server separation alone does not clarify ambiguous tool names and descriptions.
Sample Question 2 — Tool Design & MCP Integration
A research agent uses a tool named research_data with a mode parameter supporting patent search, market-metric retrieval, document summarization, and citation export. The modes have different required inputs, permissions, outputs, and failure conditions. Agents frequently omit mode-specific fields and misinterpret results. Which redesign is MOST appropriate?
- A. Split the interface into purpose-specific tools with distinct schemas, boundaries, outputs, and representative usage examples. (Correct answer)
- B. Retain one tool, make every field optional, and have the server infer the intended mode from supplied values.
- C. Retain one tool and expand its description with a complete list of every backend implementation detail.
- D. Create one tool per input field so agents can construct each research operation over multiple calls.
Correct answer: A
Explanation: Correct answer (A): The four modes represent materially different operations with distinct schemas, permissions, outputs, and failure behavior, so purpose-specific tools provide coherent boundaries. This follows the principle that tools should expose understandable capabilities rather than unrelated modes. In production, clearer schemas improve selection, validation, authorization, and result interpretation.
Why the other options are wrong:
- Option B: Making fields optional and inferring the mode preserves ambiguity and makes malformed invocations more likely.
- Option C: Additional description can help a cohesive tool, but backend implementation details do not resolve incompatible schemas and operational boundaries.
- Option D: Dividing operations by individual input fields creates excessive fragmentation and shifts unnecessary assembly work to the agent.
Sample Question 3 — Tool Design & MCP Integration
An MCP tool searches refund records. It currently returns an empty records array both when no refunds exist and when the caller lacks permission to access the billing system. The agent therefore tells some customers that no refund exists when access actually failed. Which response design BEST addresses the issue?
- A. Return an empty array for both outcomes, but add a description warning that billing access may fail.
- B. Return a fabricated placeholder record when access is denied so the agent knows data may exist.
- C. Return successful empty data only for no matches, and return an isError result with permission details for denied access. (Correct answer)
- D. Retry every empty result three times before allowing the agent to conclude that no refund exists.
Correct answer: C
Explanation: Correct answer (C): A legitimate query with no matches is a successful empty result, whereas denied access is a failed operation and should be marked with isError and meaningful permission details. This preserves the distinction between data state and execution state. In production, that distinction prevents agents from turning unavailable evidence into false customer-facing claims.
Why the other options are wrong:
- Option A: A general warning does not let the agent determine whether an individual query succeeded or failed.
- Option B: A fabricated record corrupts result semantics and could trigger incorrect downstream processing.
- Option D: Unchanged retries do not resolve permission denial and would add latency to valid empty searches.
Sample Question 4 — Tool Design & MCP Integration
An overnight research orchestrator calls several MCP tools. It automatically retries any result marked as an error, causing repeated calls for malformed dates, revoked credentials, and policy-blocked documents. It must retry temporary rate limits but avoid unchanged retries for other failures. Which design BEST meets these requirements?
- A. Return only human-readable error text and let Claude infer whether each tool invocation should be retried.
- B. Return an isError result with an error type, retryable flag, message, and relevant correction or backoff details. (Correct answer)
- C. Convert validation and permission failures into successful results containing empty data and a warning field.
- D. Apply exponential backoff to every error and stop all retries after the same fixed attempt count.
Correct answer: B
Explanation: Correct answer (B): Machine-readable error categories and retryability metadata let the orchestrator retry transient failures while correcting validation errors or escalating permission and policy failures. Human-readable details remain useful for model reasoning. This separation supports deterministic recovery and prevents wasted calls, delayed jobs, and repeated prohibited operations in production.
Why the other options are wrong:
- Option A: Natural-language errors help model reasoning, but relying on interpretation alone makes automated recovery less deterministic and harder to test.
- Option C: Representing failed operations as successful empty data conflates absence with failure and can produce unsupported conclusions.
- Option D: Backoff is appropriate for transient failures, but it cannot repair malformed inputs, revoked credentials, or policy restrictions.
Sample Question 5 — Tool Design & MCP Integration
Every contributor to a shared repository must use the team's schema-catalog MCP server in Claude Code. The server URL differs by environment, while a developer's personal note-taking server must not be imposed on teammates. Which configuration approach is BEST?
- A. Define both servers in the repository's .mcp.json and commit each developer's personal note-store path.
- B. Define the schema server in .mcp.json using an environment variable, and keep the note server in ~/.claude.json. (Correct answer)
- C. Define both servers only in ~/.claude.json and ask each contributor to reproduce the same settings manually.
- D. Define the schema server in ~/.claude.json and place the personal note server in the shared .mcp.json file.
Correct answer: B
Explanation: Correct answer (B): The team-required integration belongs in project-scoped .mcp.json, while a personal integration belongs in user-scoped ~/.claude.json. Environment-variable expansion accommodates deployment-specific values without hard-coding them into the repository. This improves reproducibility while preventing personal tools or environment details from becoming team-wide configuration.
Why the other options are wrong:
- Option A: The schema server belongs in project configuration, but committing personal paths imposes user-specific settings and may expose local details.
- Option C: Manually duplicating a required team server in user settings creates configuration drift and weakens onboarding reproducibility.
- Option D: This reverses the appropriate scopes by making the team server personal and imposing the personal server on the project.
Sample Question 6 — Tool Design & MCP Integration
Claude Code attempts to change "timeout: 30" in services.yaml, but Edit reports that the target text occurs six times. Only the billing-worker setting should change, and unrelated content must remain intact. What should Claude do FIRST?
- A. Read the relevant section, identify unique surrounding billing-worker context, and retry Edit with a specific anchor. (Correct answer)
- B. Repeat the identical Edit call until the tool chooses one of the six matching locations.
- C. Use Write immediately to replace the entire file with a newly generated version containing the change.
- D. Use Grep to replace every occurrence of timeout: 30 and then inspect the resulting file.
Correct answer: A
Explanation: Correct answer (A): Edit needs enough unique surrounding context to identify the intended location. Reading the relevant section first allows Claude to construct a precise anchor and preserve unrelated content. In production, targeted edits reduce accidental configuration changes; a full-file Write should remain a fallback only when a safe unique edit cannot be established.
Why the other options are wrong:
- Option B: Repeating the same ambiguous request adds no distinguishing context and cannot reliably select the intended occurrence.
- Option C: A full-file rewrite is unnecessarily risky when a targeted edit can likely be disambiguated and should be reserved as a fallback.
- Option D: Grep is intended for content search, and changing all six occurrences would violate the requirement to modify only billing-worker.
Sample Question 7 — Tool Design & MCP Integration
A support agent has two tools named customer_lookup and customer_search. Both descriptions say they find customer accounts, and the agent frequently passes an email address to customer_lookup even though that tool requires an immutable account ID. Which redesign BEST improves tool selection?
- A. Combine both operations into one tool with an untyped query string and let the model infer the lookup method.
- B. Rename them get_customer_by_id and search_customers, with distinct schemas, boundaries, outputs, and concise usage examples. (Correct answer)
- C. Keep both interfaces unchanged but instruct the agent to call customer_lookup before customer_search for every request.
- D. Expose only customer_lookup and require support staff to obtain an immutable account ID before using the agent.
Correct answer: B
Explanation: Correct answer (B): The tools should have names, schemas, and descriptions that clearly distinguish exact retrieval by immutable ID from search by partial attributes. The CCAR-F principle is that coherent tool boundaries and explicit usage conditions improve model-driven tool selection. In production, this reduces invalid calls, unnecessary retries, and incorrect customer matching.
Why the other options are wrong:
- Option A: A generic query appears flexible, but it removes schema-level distinctions and makes validation and operation selection less predictable.
- Option C: A fixed sequence adds unnecessary calls and does not resolve the underlying interface ambiguity.
- Option D: Removing search avoids ambiguity but also removes a legitimate capability needed when an account ID is unavailable.
Sample Question 8 — Tool Design & MCP Integration
A research agent uses one tool, run_research, with a free-form instruction argument. The tool can query public websites, a licensed financial database, and confidential internal reports. These sources have different credentials, citation formats, rate limits, and failure behavior. Auditors require source attribution and least-privilege access. Which redesign is MOST appropriate?
- A. Retain run_research but add examples showing how to mention each source in the free-form instruction.
- B. Create one tool per individual website or report so every possible source has a separate interface.
- C. Retain one tool and grant it all credentials, then return a normalized answer without source-specific metadata.
- D. Split the interface into source-class tools with typed inputs, distinct permissions, citations, and documented non-use cases. (Correct answer)
Correct answer: D
Explanation: Correct answer (D): Source-class tools create coherent boundaries that reflect materially different permissions, outputs, and failure modes without fragmenting the interface by every individual source. The CCAR-F principle is to separate operations when their security or behavioral contracts differ significantly. In production, this supports least privilege, reliable attribution, clearer validation, and safer recovery.
Why the other options are wrong:
- Option A: Examples can clarify usage, but free-form instructions do not adequately enforce distinct permission and output contracts.
- Option B: One tool per source would create excessive fragmentation and increase tool-selection ambiguity.
- Option C: Granting all credentials violates least privilege, while removing source-specific metadata fails the attribution requirement.
Keep Practicing
Take the 10-question CCAR-F quick-start test across all 5 domains, or return to the CCAR-F practice test hub for 250+ questions, exam details, and a study plan. Drill the other domains: Agentic Architecture & Orchestration, Claude Code Configuration & Workflows, Prompt Engineering & Structured Output, Tool Design & MCP Integration, and Context Management & Reliability.