QQuibank
中ENES
← Back

16 Tool Design & MCP Integration Practice Questions & Answers

Every Tool Design & MCP Integration practice question from the Claude Certified Architect – Foundations Practice Test, with the correct answer and a short explanation.

Start practice test →

  1. 1. An agent repeatedly calls the MCP tool `search_tickets` for tasks that should use `search_docs`. Both tools currently have vague one-line descriptions. What is the most effective first fix for these misrouted tool calls?

    • A.Rewrite each tool's description to state precisely what it does, when to use it, and when the other tool is the better choice✓ Answer
    • B.Rename both tools with numeric suffixes so the preferred tool sorts first in the list
    • C.Lower the model temperature so tool selection becomes deterministic
    • D.Set tool_choice to "any" so the model is always forced to pick a tool

    The model selects among available tools primarily by reading their names and descriptions, so the description is the primary routing mechanism: a detailed description that contrasts the two tools directly tells the model which one fits which task. Temperature, forcing "any" tool, and list ordering do not convey when each tool applies.

    Source: Anthropic tool use documentation — tool description best practices (descriptions are the primary tool-selection signal); CCA-F Exam Guide Domain 2Report a problem with this question

  2. 2. An MCP server exposes `get_user` and `get_user_profile`, which return overlapping data, and the model alternates between them unpredictably. Which change best follows tool-design guidance?

    • A.Order them alphabetically in the tool list so the intended default appears first
    • B.Keep both tools unchanged and let the model learn the difference from failed calls over time
    • C.Force the correct tool on every request with a forced tool_choice
    • D.Consolidate them into a single tool, or give each a description that explicitly delineates when to use it versus the other✓ Answer

    Overlapping, ambiguous tools degrade selection accuracy, and the recommended remedies are to remove the overlap (consolidate) or to disambiguate in the descriptions themselves, because descriptions are what the model uses to choose. The model does not persist learning across calls, list position is not a selection mechanism, and forcing tool_choice on every request abandons autonomous tool selection rather than fixing it.

    Source: Anthropic "Writing effective tools for agents" — consolidate or clearly delineate overlapping tools; tool description best practicesReport a problem with this question

  3. 3. An MCP tool returns the plain string "Error: request failed" for every failure, and an agent keeps retrying calls that actually fail with permanent authentication errors. What is the recommended fix?

    • A.Return isError: false with empty content so the agent simply moves on
    • B.Convert all tool failures into JSON-RPC protocol errors so the model never sees them
    • C.Return structured error responses that include fields such as errorCategory and isRetryable, so the agent can distinguish transient failures from permanent ones✓ Answer
    • D.Reduce the tool's timeout so failing calls terminate sooner

    Agents decide whether and how to retry based on the information in the tool result, so a structured error carrying a category and an explicit isRetryable flag lets the agent stop retrying permanent failures (like bad credentials) while still retrying transient ones. Hiding errors at the protocol level or faking success removes exactly the signal the model needs to self-correct, and a shorter timeout does not change the retry decision.

    Source: Anthropic "Writing effective tools for agents" / CCA-F Exam Guide Domain 2 — structured, actionable MCP error responses (errorCategory, isRetryable)Report a problem with this question

  4. 4. Under MCP, why should a tool execution failure (for example, an upstream API returning HTTP 500) be reported inside the tool result with isError: true rather than raised as a JSON-RPC protocol error?

    • A.Because JSON-RPC errors cannot carry any human-readable message text
    • B.Because tool results are passed back to the model, so it can see the failure and adjust its next action; protocol errors are reserved for client-level issues such as an unknown tool or malformed request✓ Answer
    • C.Because protocol errors are cached by the client, while tool results are never cached
    • D.Because isError: true triggers automatic retries by the MCP client

    The MCP specification distinguishes two error channels: execution errors go inside the result with isError: true precisely so the content is surfaced to the LLM, which can then read the failure and self-correct (retry, change inputs, or pick another tool), whereas JSON-RPC protocol errors address client-side problems like invalid tool names or arguments. There is no caching distinction, no automatic client retry tied to isError, and JSON-RPC errors do carry message text.

    Source: MCP specification, Tools — Error handling: execution errors reported in the result with isError: true so the LLM can see and self-correct; protocol errors for client-level issuesReport a problem with this question

  5. 5. A multi-agent system has an orchestrator and three specialist subagents. A developer attaches all 40 available MCP tools to every subagent, and tool-selection accuracy drops noticeably. Which approach best addresses this?

    • A.Force every subagent's tool calls with a forced tool_choice on each turn
    • B.Scope the tool distribution so each subagent receives only the tools relevant to its role✓ Answer
    • C.Increase max_tokens so the model has more room to reason over all 40 tool definitions
    • D.Keep all tools on every subagent but add prompt instructions listing which tools each subagent should prefer

    Every tool definition competes for the model's attention, so a large, mostly irrelevant toolset increases the chance of picking the wrong tool; scoping each subagent to only its role-relevant tools shrinks the decision space, which directly improves selection accuracy and also saves context. Prompt hints still leave 40 candidates in context, forcing tool_choice removes the agent's judgment, and max_tokens does not affect how many tools compete for selection.

    Source: CCA-F Exam Guide Domain 2 — scoped tool distribution across agents; Anthropic multi-agent guidance: give each agent only the tools its role requiresReport a problem with this question

  6. 6. A workflow must guarantee that Claude's next response calls the specific tool `record_summary` instead of answering in plain text or choosing a different tool. Which tool_choice setting achieves this?

    • A.{"type": "any"}
    • B.{"type": "auto"}
    • C.{"type": "none"}
    • D.{"type": "tool", "name": "record_summary"}✓ Answer

    The tool_choice values differ in how much freedom the model keeps: "auto" lets the model decide whether to use any tool at all, "any" forces the model to use some tool but not a particular one, and "none" prevents tool use entirely; only {"type": "tool", "name": ...} forces a call to the one named tool, which is what a guaranteed structured-output step requires.

    Source: Claude API tool use documentation — tool_choice parameter: auto (model decides), any (some tool required), tool (specific tool forced), none (no tools)Report a problem with this question

  7. 7. A team wants every member to get the same MCP server configuration from the repository, but the server requires an API key that must never be committed. Which setup follows Claude Code guidance?

    • A.Have each developer add the server at user scope so nothing at all is shared through the repository
    • B.Commit .mcp.json with the key written inline, since Claude Code gitignores that file automatically
    • C.Store the key in ~/.claude.json and commit that file to the repository
    • D.Commit a project-scoped .mcp.json that references the key as ${API_KEY}, and have each developer set that environment variable locally✓ Answer

    Project scope exists exactly for this: .mcp.json at the project root is designed to be checked into version control, and Claude Code expands ${VAR} references in fields like env, headers, url, command, and args at load time, so the shared file carries the structure while each machine supplies its own secret. Claude Code does not gitignore .mcp.json for you, user scope sacrifices the shared-configuration requirement, and ~/.claude.json is a per-user home file that should never be committed.

    Source: Claude Code MCP documentation — Project scope (.mcp.json designed for version control) and Environment variable expansion in .mcp.json (${VAR} in command, args, env, url, headers)Report a problem with this question

  8. 8. A committed .mcp.json contains "Authorization": "Bearer ${API_KEY}" with no default value. What happens when a developer who has not set API_KEY starts Claude Code?

    • A.The variable silently expands to an empty string with no warning
    • B.Claude Code refuses to load the entire .mcp.json file
    • C.The configuration still loads, but the literal text ${API_KEY} is left in the value and a missing-variable warning is reported for that server✓ Answer
    • D.Claude Code prompts interactively for the value and writes it back into .mcp.json

    Claude Code's expansion rule is that a referenced variable with no value and no :-default fallback is left as the literal ${VAR} text and a missing-variable warning is reported for that server, while the configuration as a whole still loads. This is why teams are advised to either document the required variables or use the ${VAR:-default} form so the server starts with an intended value.

    Source: Claude Code MCP documentation — Environment variable expansion in .mcp.json: unset variable without a default leaves the literal ${VAR} and reports a missing-variable warning; config still loadsReport a problem with this question

  9. 9. The same server name "github" is configured both at local scope (stored in ~/.claude.json under the project's entry) and at project scope (in the repo's .mcp.json), with different settings in each. How does Claude Code resolve this?

    • A.It connects once using the local-scope entry in full, because local scope takes precedence over project scope and entries are not merged✓ Answer
    • B.It connects to both entries, resulting in two copies of the server's tools
    • C.It merges fields from both entries into one combined configuration
    • D.It uses the project-scope entry, because team-shared configuration always overrides personal configuration

    The scope precedence order is local, then project, then user: when the same server name appears in multiple scopes, Claude Code connects once using the entire entry from the highest-precedence source, and fields are never merged across scopes. This ordering lets an individual developer override a team-shared server definition for their own machine without editing the committed file.

    Source: Claude Code MCP documentation — Scope hierarchy and precedence: local > project > user; the entire highest-precedence entry is used and fields are not mergedReport a problem with this question

  10. 10. An MCP server needs to expose a read-only database schema document that users bring into context themselves (for example via @ mentions in Claude Code), rather than an action the model invokes. Which MCP primitive fits this need?

    • A.A tool, because every capability an MCP server exposes must be a tool
    • B.A sampling request, because the server should push the schema into the model on its own
    • C.A resource, because resources expose URI-addressed data for the application or user to bring into context, while tools are model-invoked actions✓ Answer
    • D.A prompt, because prompts are the MCP primitive for storing static documents

    MCP defines resources as the application-driven primitive for exposing data: each resource is addressed by a URI, and the host application or user decides when to attach it as context, which is exactly how Claude Code surfaces resources through @ mentions in the format @server:protocol://path. Tools are model-controlled actions, prompts are user-invoked templates, and sampling is a server-initiated request for LLM completions, so none of them matches passive reference data.

    Source: MCP specification — Resources (application-driven, URI-addressed data) vs Tools (model-controlled); Claude Code MCP documentation, "Use MCP resources" (@server:protocol://resource/path)Report a problem with this question

  11. 11. Which statement correctly matches Claude Code's built-in tools to their intended selection strategy?

    • A.Glob finds files by name pattern, Grep searches file contents with regex, and Edit makes a targeted string replacement in an existing file✓ Answer
    • B.Write appends to the end of a file without overwriting it, so it is the safest choice for incremental changes
    • C.Bash with cat, grep, and sed should be preferred over Read, Grep, and Edit for routine file work
    • D.Grep finds files by name pattern, Glob searches file contents, and Write is preferred for small in-place edits

    The built-in tools divide the work by mechanism: Glob matches file paths against patterns like **/*.ts, Grep runs regex searches over file contents, Read returns file contents, Edit performs an exact targeted replacement that leaves the rest of the file intact, and Write overwrites an entire file, which is why Edit is preferred for small changes. Claude Code guidance also says to prefer these dedicated tools over Bash equivalents like cat, grep, and sed.

    Source: Claude Code built-in tools reference — Glob (path patterns), Grep (content regex), Read, Edit (targeted replacement), Write (full overwrite); dedicated tools preferred over Bash equivalentsReport a problem with this question

  12. 12. A document-processing agent exposes a single generic tool, process_document(action, doc_url), where action accepts 'extract', 'summarize', or 'verify'. Production logs show the model frequently passes the wrong action value, conflating data extraction with summarization. Which redesign most reliably fixes the misrouting?

    • A.Set tool_choice to 'any' on every request so the model is guaranteed to invoke process_document
    • B.Add strict enum validation on the action parameter so invalid values return isError, letting the agent retry with a corrected value
    • C.Split the tool into three purpose-specific tools with distinct, non-overlapping names (e.g., extract_data_points, summarize_content, verify_claim_against_source), each with its own input/output contract and a description stating when to use it versus the alternatives✓ Answer
    • D.Keep the single tool but add a system-prompt rule that maps keywords in each user request to the correct action value

    Tool descriptions and names are the primary mechanism the model uses for tool selection, and a single multi-mode tool forces the model to encode intent inside a parameter, where that guidance is weakest. Splitting the generic tool into purpose-specific tools with distinct names, defined input/output contracts, and differentiated descriptions moves the decision to the tool-selection step, which is far more reliable. Enum validation only rejects mistakes after they happen, keyword rules in the system prompt can create unintended tool associations, and tool_choice 'any' guarantees a call but not the right mode.

    Source: CCAR-F Exam Guide, Domain 2, Task Statement 2.1 — splitting generic tools into purpose-specific tools with defined input/output contracts (e.g., analyze_document → extract_data_points / summarize_content / verify_claim_against_source); Anthropic tool-use documentation (descriptions drive tool selection)Report a problem with this question

  13. 13. A platform team publishes an MCP server whose code_search tool uses a semantic index that resolves symbol references across an entire monorepo. In Claude Code sessions, the agent keeps using the built-in Grep tool instead and misses cross-package results. The MCP tool's description is just 'Searches code.' What is the recommended fix?

    • A.Rewrite the tool's description to explain its capabilities and outputs in detail — semantic, symbol-aware search across the whole monorepo with ranked file-and-line results — and when to prefer it over plain text search✓ Answer
    • B.Rename the MCP tool so its name matches the built-in tool it is meant to replace
    • C.Deny the built-in Grep tool in permission settings so the agent has no alternative to the MCP tool
    • D.Move the server from user-level configuration to project-level .mcp.json so its tools are ranked ahead of built-in tools

    The agent chooses among all available tools based on their descriptions, so a minimal description like 'Searches code.' gives the model no reason to prefer the MCP tool over a familiar built-in like Grep. The documented remedy is to enhance the MCP tool's description with detailed capabilities, outputs, and guidance on when to use it. Configuration scope only determines where the server is shared (team vs personal), not tool preference, renaming cannot make an MCP tool shadow a built-in (MCP tool names are server-prefixed), and denying Grep removes a tool that remains appropriate for simple text searches.

    Source: CCAR-F Exam Guide, Domain 2, Task Statement 2.4 — enhancing MCP tool descriptions to explain capabilities and outputs in detail, preventing the agent from preferring built-in tools (like Grep) over more capable MCP tools; docs.claude.com/en/docs/claude-code/mcpReport a problem with this question

  14. 14. An architect must give Claude Code access to two systems: Jira, used only with standard operations (creating, searching, and transitioning issues), and an internal deployment-approval system with bespoke workflow rules. Engineering capacity is limited. Which integration strategy is recommended?

    • A.Adopt community MCP servers for both, adapting a generic workflow server to the internal approval system
    • B.Adopt an existing community MCP server for Jira and invest custom MCP server development only in the internal deployment-approval workflow✓ Answer
    • C.Build custom MCP servers for both systems so the team fully controls tool naming and error handling
    • D.Skip MCP for Jira and have the agent call the Jira REST API directly through Bash, reserving MCP for the internal system

    The recommended principle is to choose existing community MCP servers for standard integrations — a Jira community server already implements and maintains the common operations — and reserve scarce custom-development effort for team-specific workflows that no community server covers, such as the bespoke approval system. Building a duplicate Jira server wastes limited capacity, bending a generic community server around a bespoke internal system rarely models its rules correctly, and raw REST calls through Bash lose the typed tool interfaces and descriptions that make MCP tools reliably selectable by agents.

    Source: CCAR-F Exam Guide, Domain 2, Task Statement 2.4 — choosing existing community MCP servers over custom implementations for standard integrations (e.g., Jira), reserving custom servers for team-specific workflowsReport a problem with this question

  15. 15. In a multi-agent research system, a retrieval subagent queries two sources: source A returns an HTTP 503 (service temporarily unavailable) and source B returns a successful response containing zero matching records. Today the subagent immediately reports 'retrieval failed' to the coordinator, which restarts the entire research task. Which redesign follows the recommended error-handling pattern?

    • A.Return a generic 'retrieval failed' error marked isRetryable: true so the coordinator re-runs the entire subagent task
    • B.Have the subagent retry the transient 503 locally with backoff, treat source B's empty result as a valid successful answer, and only if source A still fails propagate a structured error that includes B's results and what was attempted✓ Answer
    • C.Have the subagent retry both sources until source B returns at least one record, then report success
    • D.Propagate both outcomes to the coordinator unchanged so it has full visibility and can decide whether to retry each source

    The recommended pattern is local recovery inside the subagent for transient failures, propagating to the coordinator only errors that cannot be resolved locally — accompanied by partial results and a record of what was attempted — so the coordinator never discards work that already succeeded. It also requires distinguishing access failures (which need retry decisions) from valid empty results, which represent successful queries with no matches: retrying source B until it returns records, or restarting the whole task, treats a correct answer as an error and wastes turns.

    Source: CCAR-F Exam Guide, Domain 2, Task Statement 2.2 — implementing local error recovery within subagents for transient failures, propagating only unresolvable errors with partial results and what was attempted; distinguishing access failures from valid empty resultsReport a problem with this question

  16. 16. An agent must find every call site of formatCurrency in a large TypeScript codebase, but most packages import it through a wrapper module, lib/format/index.ts, which re-exports it under different aliases. A single Grep for 'formatCurrency' returns only the wrapper itself. Which exploration strategy is recommended?

    • A.Re-run Grep for 'formatCurrency' with case-insensitive matching to catch alias variations
    • B.Read every file in the repository upfront so no call site can be missed
    • C.Read the wrapper module first to identify every name it exports, then Grep for each exported name across the codebase, Reading only the matching files to confirm real usage✓ Answer
    • D.Run Glob for **/*format*.ts and Read each matching file, since usage will be in similarly named files

    Tracing function usage across wrapper modules requires first enumerating the wrapper's exported names, because downstream call sites reference the alias rather than the original function name; Grepping for each exported name and then Reading only the matching files builds codebase understanding incrementally instead of reading everything upfront. Reading the whole repository floods the context window with irrelevant content, Glob matches file paths and cannot find call sites (which can live in any file), and case-insensitive matching still misses aliases whose names differ entirely from formatCurrency.

    Source: CCAR-F Exam Guide, Domain 2, Task Statement 2.5 — tracing function usage across wrapper modules by first identifying all exported names, then searching for each name; building codebase understanding incrementally with Grep to find entry points, then Read to trace flowsReport a problem with this question

Practice questions based on the official Claude Certified Architect – Foundations (CCAR-F) exam guide and Anthropic's public documentation. This is an independent study tool, not affiliated with or endorsed by Anthropic, and does not grant certification. The real exam is 60 questions, 120 minutes, passing at a scaled 720/1000, delivered via Pearson VUE ($125). Official certification page →