20 Tool Design & MCP Integration Practice Questions & Answers

1. 1. A customer support agent exposes MCP tools get_customer and lookup_order, each with a one-line description ('Retrieves customer information' / 'Retrieves order details'). Production logs show that for messages like 'where is my package for 88-2210?' the agent calls get_customer roughly 30% of the time and then answers with no shipping data. What is the most effective FIRST step?

   • A.Merge the two tools into a single lookup_entity tool that returns customer and order data together
   • B.Add a deterministic keyword and regular-expression layer that pre-selects the tool before the model sees the message
   • C.Rewrite both descriptions to state accepted input formats, representative user phrasings, the fields returned, and an explicit boundary sentence pointing to the other tool✓ Answer
   • D.Add six few-shot examples of correct routing to the system prompt

   The description is the primary field the model reads to decide whether a tool applies, so two near-identical minimal descriptions are the actual root cause of the misrouting; differentiating them (inputs, example queries, outputs, and an explicit 'use the other tool when...' boundary) is the lowest-effort intervention that removes the ambiguity. Few-shot examples add token overhead without repairing the descriptions, a regex router bypasses the model's language understanding, and merging erases a distinction that still matters for permissions and payload size.

   Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.1 (tool descriptions as the primary tool-selection mechanism)Report a problem with this question

2. 2. The same support agent must verify identity with get_customer before calling process_refund. The system prompt says so, yet in about 4% of transcripts process_refund is called first. Both tools already have detailed, well-differentiated descriptions. What is the best fix?

   • A.Remove process_refund and route every refund through escalate_to_human
   • B.Strengthen the system-prompt wording and add worked examples of the correct order
   • C.Expand the process_refund description to explain in more detail when it should be used
   • D.Enforce the order programmatically: a prerequisite gate or tool-call interception hook that rejects process_refund unless verification already succeeded in this session✓ Answer

   This is a tool-ORDERING and business-rule compliance problem, not a tool-selection problem: prompt instructions and examples have a non-zero failure rate, so only a programmatic prerequisite or interception hook can guarantee the invariant on every call. Better descriptions fix which tool gets chosen, not whether a required prior step actually ran, and deleting the tool removes a capability the business needs.

   Source: Anthropic Claude certification (Architect – Foundations), Domain 1.4/2.1 (programmatic enforcement for tool ordering and business rules vs. description quality for tool selection)Report a problem with this question

3. 3. A healthcare intake agent has a tool described as 'Returns formulary tier and prior-authorization status for a drug.' Reviewers find the agent frequently answers coverage questions from prior knowledge instead of calling it. Which change most reliably increases correct triggering?

   • A.Train a separate intent classifier that detects coverage questions and injects a reminder
   • B.Rewrite the description prescriptively: state that it must be called whenever a user asks whether a medication is covered, what it will cost, or whether prior authorization is needed, and that coverage must never be answered from prior knowledge✓ Answer
   • C.Add a self-reported confidence field to the answer so low-confidence replies trigger a lookup
   • D.Set tool_choice to 'any' for the entire conversation so a tool is always called

   Descriptions that are prescriptive about WHEN to call a tool, not merely what it returns, measurably improve triggering because the model reads the description as its decision rule at selection time. Forcing tool_choice 'any' for the whole conversation makes the model call something even on greetings, self-reported confidence is unreliable, and a separate classifier is over-engineering for an information deficit in one field.

   Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.1 (descriptions must state when to use a tool, its boundaries and edge cases)Report a problem with this question

4. 4. A logistics agent calls analyze_shipment_document(doc_id, mode) where mode is 'extract', 'summarize', or 'verify'. The output shape differs per mode, downstream steps break, and the agent often passes the wrong mode. What is the best redesign?

   • A.Keep one tool and force tool_choice to it so at least the tool is always selected
   • B.Split it into extract_shipment_fields, summarize_shipment_doc and verify_shipment_against_po, each with its own input schema and a single defined output contract✓ Answer
   • C.Keep one tool and add post-processing that infers which mode ran from the shape of the returned payload
   • D.Keep one tool and lengthen its description to enumerate all three modes and their outputs

   A tool whose behavior and return type change with a mode argument gives neither the model nor the harness a stable contract, so the fix is purpose-specific tools with defined input and output contracts. Describing the modes at length leaves the ambiguity in place, inferring the mode from output shape is fragile guesswork, and forcing tool_choice does not make the model pick the right mode.

   Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.1 (split generic tools into purpose-specific tools with defined I/O contracts)Report a problem with this question

5. 5. A developer-productivity agent has exactly one tool: run_shell_command(command: string). Platform engineering now requires human approval for production migrations, an audit record of every privileged action, and safe parallel execution of read-only queries. What is the best tool-surface change?

   • A.Add dedicated tools with typed arguments for the actions that need gating, auditing or parallel-safety (for example run_migration(env, migration_id) and read_service_log(service, since)), keeping the shell only as a general fallback✓ Answer
   • B.Replace the shell tool with a single execute_task(intent: string) tool so the harness receives natural-language intent instead of a command
   • C.Keep only the shell tool and add a system-prompt rule telling the agent to ask before running destructive commands
   • D.Keep the shell tool and add a wrapper that classifies the command string with regular expressions to decide whether to prompt for approval

   A general-purpose shell tool hands the harness an opaque command string, which cannot be reliably validated, rendered, audited, or marked safe to run in parallel; promoting those specific actions into dedicated tools with typed arguments gives the harness structured values it can gate and log. Prompt rules have no enforcement power, an intent string is even more opaque than a command, and regex classification of arbitrary shell text is exactly the reverse-engineering that typed arguments exist to avoid.

   Source: Anthropic Claude certification (Architect – Foundations), Domain 2 (tool-surface design: general-purpose escape hatch vs. dedicated tools with typed, gateable arguments)Report a problem with this question

6. 6. A fintech reconciliation agent posts ledger adjustments through a generic write_record(table, payload) tool. Auditors find cases where the agent overwrote an entry that a human had updated after the agent read it. Which change best prevents this class of failure?

   • A.Promote the action into its own tool, post_ledger_adjustment(entry_id, expected_version, amount, reason), whose implementation rejects the write when the stored version no longer matches✓ Answer
   • B.Instruct the model in the system prompt to re-read the entry immediately before every write
   • C.Add automatic retry with exponential backoff whenever a write fails
   • D.Disable parallel tool calls so the agent performs at most one write per turn

   One of the standard reasons to promote an action into its own tool is that an invariant must be checked on every call — here, rejecting a stale write — and only a dedicated tool with the version as a typed argument lets the harness enforce it deterministically. Re-reading on instruction still leaves a race window, serializing writes does not stop a concurrent human editor, and retrying simply re-applies a write that was wrong to begin with.

   Source: Anthropic Claude certification (Architect – Foundations), Domain 2 (promote an action into a dedicated tool when an invariant must be checked, a security boundary crossed, custom presentation is needed, or parallel-safety must be declared)Report a problem with this question

7. 7. An MCP server's lookup_order tool receives a well-formed request for an order that exists, but the downstream order-management system returns HTTP 503. How should the server report this so the agent behaves well?

   • A.Return a normal tools/call result marked isError: true, with content describing the upstream failure and whether a retry could succeed✓ Answer
   • B.Return a JSON-RPC protocol error so the failure is handled by the transport layer rather than the model
   • C.Raise the exception out of the handler and let the session terminate so the operator notices
   • D.Return a successful result with empty content so the conversation continues without an error state

   MCP distinguishes a tool execution error, reported as isError: true inside the tools/call result, from a JSON-RPC protocol error such as an unknown tool or malformed request; clients pass execution errors back to the model so it can adapt, retry, or explain, which a protocol error does not enable. Returning empty success silently hides the failure, and crashing the session removes the model's chance to recover.

   Source: Model Context Protocol specification, Tools — error handling (isError on the tools/call result vs. JSON-RPC protocol errors); Exam Guide Domain 2, Task 2.2Report a problem with this question

8. 8. Every tool on an internal MCP server returns the same failure text, 'Operation failed.' Telemetry shows the agent retrying permanently-invalid requests up to the retry cap and abandoning outages that would have cleared in seconds. What is the best remedy?

   • A.Include the full server stack trace in the error text so the model has maximum information
   • B.Add a system-prompt instruction telling the agent to retry at most twice and then escalate
   • C.Alongside isError, return a structured payload naming the failure category (transient, validation, business rule, permission), whether a retry could plausibly succeed, and a human-readable explanation✓ Answer
   • D.Apply a uniform client-side policy of three retries with exponential backoff to every error result

   Uniform generic errors strip the agent of the information it needs to choose between retrying, explaining to the customer, and escalating, so the structural fix is to carry the category, retryability and a readable reason inside the error content (these fields are a design convention placed in the payload, not schema fields defined by the protocol). A blanket retry policy still wastes calls on validation and business-rule failures, a prompt rule cannot infer a category that was never sent, and a raw stack trace is noise the model cannot act on.

   Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.2 (structured error responses: category, retryability, customer-safe explanation)Report a problem with this question

9. 9. In a research system, search_corpus can (a) run successfully and match zero documents, or (b) fail because the connector times out. Today both cases return the same 'no results' payload, and the final report has begun stating that no evidence exists on topics that were never actually searched. What is the correct design?

   • A.Return zero matches as a successful result containing an empty array and the query that ran, and return the timeout as isError with a transient, retryable category✓ Answer
   • B.Return both as successes so the workflow is never blocked by an infrastructure problem
   • C.Keep both payloads identical and let the coordinator infer which case occurred from the call latency
   • D.Return both as errors so the coordinator always retries and never reports a false absence

   A successful query with zero matches is a valid, informative answer — evidence of absence — while a timeout means the question was never answered, so the two must be reported differently for the agent to decide between retrying and concluding. Treating empty results as errors triggers pointless retries, treating failures as successes silently fabricates coverage, and inferring the case from latency is guesswork rather than a contract.

   Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.2 (distinguish access failure from a valid empty result)Report a problem with this question

10. 10. A multi-agent research system gives its coordinator, web-search, document-analysis and synthesis subagents the same set of 18 tools. Reviews show the synthesis agent issuing web searches and the document agent calling report-formatting tools, with a rising rate of wrong-tool calls. What is the best structural change?

    • A.Keep all 18 tools everywhere and add a paragraph to each subagent's system prompt listing the tools it must not use
    • B.Remove tools from the subagents entirely and have every tool call routed through the coordinator
    • C.Consolidate the 18 tools into five multi-purpose tools that take a mode argument, so the surface is smaller
    • D.Scope each subagent to the four or five tools its role actually requires, adding a narrow cross-role tool only where a genuine high-frequency need exists, such as a scoped verify_fact for the synthesis agent✓ Answer

    Selection reliability degrades as the tool surface grows, and agents handed tools outside their specialization will misuse them, so the fix is least-privilege, role-scoped tool sets plus a small number of narrow cross-role tools for genuinely frequent needs. Prompt-level prohibitions have no enforcement, mode-argument consolidation recreates the generic-tool problem, and funnelling every call through the coordinator adds a bottleneck without improving selection.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.3 (distribute scoped tool sets across agents; oversized tool libraries degrade selection)Report a problem with this question

11. 11. An intake step must always emit a structured classification, but which of three extraction schemas applies depends on the document type, which is unknown until the model inspects the document. With default settings the model sometimes replies in prose instead of calling a tool. Which configuration fits best?

    • A.Set tool_choice to a specific named tool so a structured result is guaranteed on every request
    • B.Leave tool_choice on 'auto' and add an instruction that the model must always call a tool
    • C.Set tool_choice to 'any', so the model must call one of the three extraction tools while still choosing the schema that matches the document✓ Answer
    • D.Set tool_choice so that no tools may be called, then parse the classification out of the prose reply

    'any' guarantees that some tool call is produced while leaving the choice of which schema to the model, which is exactly the requirement when the correct schema is not known in advance. Forcing one named tool would apply the wrong schema to two document types out of three, 'auto' permits a text-only answer no matter what the prompt says, and forbidding tools reintroduces the prose-parsing problem the structured output was meant to eliminate.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.3 (tool_choice: auto, any, and forced named tool)Report a problem with this question

12. 12. A team wants the whole engineering org to share one MCP server for its ticketing system, while one engineer keeps a personal experimental scraper server. The ticketing server needs an API token that must never appear in version control. What is the correct configuration?

    • A.Declare both servers in the user-level configuration and circulate setup instructions so each engineer adds the ticketing server manually
    • B.Commit the project .mcp.json with a placeholder token that each engineer edits locally after cloning
    • C.Declare both servers in the project .mcp.json with the token written inline, and add that file to .gitignore
    • D.Declare the ticketing server in the project-level .mcp.json committed to version control, referencing the token through environment-variable expansion, and declare the experimental server in the user-level configuration✓ Answer

    Project-level .mcp.json is the mechanism for shared team tooling precisely because it is committed, while user-level configuration is where personal or experimental servers belong; environment-variable expansion inside the file keeps the secret out of version control without giving up sharing. Gitignoring the project file defeats the point of sharing it, and placeholder tokens edited locally guarantee accidental commits of real credentials.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.4 (project vs. user MCP scoping; ${ENV_VAR} expansion for credentials)Report a problem with this question

13. 13. Before nearly every analytics question, an agent burns several tool calls listing tables and describing columns in a 400-table warehouse. The schema changes rarely. What is the most appropriate MCP-side change?

    • A.Paste the full data-definition language for all 400 tables into the system prompt permanently
    • B.Expose the schema catalog as MCP resources, which the application supplies as read-only context, and keep tools for the actions that actually query data✓ Answer
    • C.Add a list_tables tool and instruct the agent in the system prompt to call it as its first action every time
    • D.Publish the schema as an MCP prompt template that the user invokes before asking a question

    MCP separates model-controlled tools (actions the model decides to invoke), application-controlled resources (read-only content the application supplies), and user-controlled prompts (templates the user triggers); a schema catalog is exactly the application-controlled context that resources exist to deliver, eliminating exploratory calls. Adding another tool keeps paying the round-trip cost, pasting 400 tables of DDL wastes context on every request, and a user-triggered prompt makes correct behavior depend on the user remembering to run it.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.4 (MCP resources as content catalogs; tools model-controlled, resources application-controlled, prompts user-controlled)Report a problem with this question

14. 14. A developer asks an agent to find every call site of computeTaxBasis and, separately, to list every file matching **/*.spec.ts. Which use of the built-in tools is correct?

    • A.Use Grep for the identifier, because Grep searches file contents, and Glob for the path pattern, because Glob matches file paths and names✓ Answer
    • B.Use Read on every file under the source tree and reason over the contents for both requests
    • C.Use Glob for the identifier and Grep for the path pattern
    • D.Use Edit's match behavior to locate the identifier and Read to enumerate the test files

    Grep is the content-search tool — function callers, error strings, import statements — while Glob matches paths and filenames against a pattern, so each request maps to exactly one of them. Reading every file exhausts context for no benefit, and Edit is an editing primitive that requires a unique anchor rather than a search tool.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.5 (Grep searches file contents; Glob matches file paths)Report a problem with this question

15. 15. An Edit call fails because the anchor text 'return null;' appears twelve times in the target file. What should the agent do next?

    • A.Report the failure and ask the developer to make the edit by hand
    • B.Use a Bash one-liner to apply the change by line number instead
    • C.Expand the anchor to include enough surrounding text to be unique, or fall back to Read followed by Write of the full updated file✓ Answer
    • D.Re-issue the same Edit with replace-all enabled so all twelve occurrences are updated

    Edit is anchored on text that must match uniquely, so a non-unique match is a signal to re-anchor with more surrounding context or to switch to the whole-file path of Read plus Write. Replace-all would modify eleven sites that were never meant to change, editing by line number in a shell is fragile and unverified, and handing the work back to the developer abandons a task the built-in tools can complete.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2, Task 2.5 (Edit requires a unique anchor; fall back to Read + Write)Report a problem with this question

16. 16. In one turn the model emits three tool calls. The harness finishes the first quickly and, to reduce latency, sends that single result back immediately, planning to deliver the other two in a later turn. What is wrong with this, and what should the harness do?

    • A.The harness should cancel the two slower calls and let the model re-request them if it still needs them
    • B.Nothing is wrong, provided the remaining results arrive before the conversation ends
    • C.It is acceptable only if the two slower calls are read-only, since read-only results can be reordered safely
    • D.It leaves tool calls from that turn unanswered; every result from a single turn must be returned together in one follow-up message✓ Answer

    When a turn contains parallel tool calls, the conversation is only well-formed again once every one of those calls has a matching result in the same follow-up message; splitting them leaves dangling calls and an inconsistent history the model must reason over. Read-only status does not change the pairing requirement, and cancelling calls the model deliberately issued in parallel throws away the latency benefit that parallelism exists for.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2 (parallel tool calls: all results from a turn are returned together)Report a problem with this question

17. 17. An architect is deciding how two capabilities should execute: a general web-search capability, and a customer-lookup capability whose data is regulated personal information that must stay inside the company's own network and be logged there. Which allocation is best and why?

    • A.Execute customer lookup on the provider's infrastructure with an allowlist of permitted fields, and build the web search in-house for full control
    • B.Execute both inside the company's application, because a uniform execution model is simpler to reason about than a mixed one
    • C.Execute both on the provider's infrastructure, since a well-defined schema keeps the regulated data structured wherever the tool runs
    • D.Let the web-search capability run as a provider-executed tool, since the company then maintains no crawling infrastructure, while customer lookup stays a tool the company's own application executes, keeping regulated data and its audit trail inside its environment✓ Answer

    Who executes a tool determines where credentials and data actually live and who carries the operational burden: a provider-executed tool removes the need to build and run that capability, while a client-executed tool keeps the data path, access controls and logs inside your own environment. Uniformity for its own sake either forces you to build a crawler you do not need or pushes regulated data outside your boundary, and a field allowlist does not change the fact that the lookup would run outside the company's network.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2 (tools executed by your own application vs. tools executed on the provider's infrastructure)Report a problem with this question

18. 18. An internal platform now aggregates about 300 tools from a dozen MCP servers, and every request loads all of their schemas. Latency has grown and wrong-tool selection has become common. What is the most appropriate architectural response?

    • A.Split the platform into a dozen separate agents, one per server, and route each request with a trained classifier
    • B.Truncate every tool description to a single line so the full library costs fewer tokens
    • C.Keep a small always-loaded core set and discover the remaining tool definitions on demand, loading a schema only when the task at hand calls for it✓ Answer
    • D.Move to a configuration with a larger context window so all 300 schemas fit comfortably

    Loading every schema up front costs tokens on every request and enlarges the surface the model must discriminate across, so on-demand discovery — a small core plus definitions fetched when relevant — addresses both symptoms at once. A larger window pays the token cost anyway and does nothing for selection accuracy, truncating descriptions attacks the very field that drives correct selection, and a trained router replaces the model's language understanding with a component that must itself be maintained.

    Source: Anthropic Claude certification (Architect – Foundations), Domain 2 (scaling a large tool library; on-demand tool discovery instead of loading every schema up front)Report a problem with this question

19. 19. A team has built a bespoke integration for its internal ticketing system inside one application. Two other internal clients now need the same capability, and a third is planned. What is the most appropriate approach?

    • A.Have each application call the ticketing system's own API directly and standardize only the tool descriptions across teams
    • B.Expose the integration as a plain HTTP API and write a bespoke tool wrapper inside each client application
    • C.Copy the integration code into each application and keep the copies in sync with a shared library release process
    • D.Implement the integration once as an MCP server that exposes its tools and resources over a defined transport, so any MCP client can connect to it instead of each application reimplementing it✓ Answer

    The problem MCP was created to solve is exactly this: an open standard so that a tool integration written once can be reused by any compliant client, instead of being re-implemented per application. Copied code and per-client wrappers reproduce the same drift and maintenance burden the standard removes, and standardizing only descriptions leaves every client owning its own integration logic.

    Source: Model Context Protocol — purpose and client/server roles (write an integration once, reuse it across clients); Exam Guide Domain 2, Task 2.4Report a problem with this question

20. 20. An engineer proposes connecting an unreviewed community MCP server to a production agent. It would run with the agent's existing credentials, and its tool descriptions would be loaded into the model's context alongside the team's own tools. Which consideration should drive the decision?

    • A.The risk is bounded because tools from different MCP servers cannot be selected in the same conversation
    • B.There is no meaningful risk as long as the server exposes only read-only tools and no write operations
    • C.Connecting a third-party server extends the trust boundary: its tool descriptions become text the model acts on and its tools run with whatever access is granted, so it must be reviewed, pinned to a known version and scoped to least privilege before use✓ Answer
    • D.The risk is limited to availability, since a third-party server can slow the agent down but cannot influence its decisions

    Tools from all configured servers are discovered at connection time and are available simultaneously, and a server's tool descriptions are instructions the model reads when choosing what to do, so an untrusted server can both influence behavior and act with the access you grant it. Read-only tools still exfiltrate data and still inject text into the model's context, which is why review, version pinning and least-privilege scoping are the controls that matter.

    Source: Model Context Protocol — security considerations for connecting third-party servers; Exam Guide Domain 2, Task 2.4 (tools from all configured servers are discovered and available simultaneously)Report 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 →