Skip to content

CCAR-F · Domain 2: Tool Design & MCP Integration · 18% of the exam

Task 2.1: Design effective tool interfaces with clear descriptions and boundaries

Tool names and descriptions as the main signal Claude uses to pick a tool: inputs, outputs, examples and boundaries, removing overlap between similar tools, and system-prompt wording that pulls Claude toward the wrong one.

Study it

Sample questions

Try each one before opening the answer. Every option is explained, with the Anthropic documentation page that proves it.

Question 1 · choose 1

Your developer productivity agent has two MCP tools, query_logs and search_events, each described only as "Searches records." Engineers ask about failed deployments and about application errors, and Claude often sends deployment questions to query_logs. Both tools accept the same service and time-range inputs. What is the best first change?

  1. AForce search_events with tool_choice whenever a request mentions a deployment
  2. BRename both tools after what they search and say in each description when to use it instead of the other
  3. CSet strict: true on both tools so that Claude's inputs always match their schemas
  4. DAdd a third tool that Claude calls first to decide which of the two search tools fits the question
Show the answer and why
  • AForce search_events with tool_choice whenever a request mentions a deployment

    Incorrect

    Forcing a tool needs your code to classify every request first, and it leaves the two tools as hard to tell apart as before.

  • BRename both tools after what they search and say in each description when to use it instead of the other

    Correct

    Names and descriptions are the main signal Claude uses to choose a tool; spelling out each tool's source, inputs and boundary removes the overlap.

  • CSet strict: true on both tools so that Claude's inputs always match their schemas

    Incorrect

    Strict mode guarantees valid inputs; both tools already accept the same inputs, so it does nothing for choosing between them.

  • DAdd a third tool that Claude calls first to decide which of the two search tools fits the question

    Incorrect

    An extra tool adds a call to every question and another description to get right, while the two descriptions stay ambiguous.

Minimal, near-identical descriptions cause misrouting. Give each tool a name and description that state what it covers, what it expects and returns, and when to use it instead of the similar tool.

Question 2 · choose 1

In your research system one tool, analyze_document, takes a free-text instruction. Agents use it to pull figures out of a paper, to summarize a section, and to check whether a source supports a claim, and it returns free text each time. The synthesis agent cannot tell which kind of output it has received and often misreads it. What should you do?

  1. AAdd a final model call that rewrites every analyze_document result into one generic schema before the synthesis agent reads it
  2. BReplace it with a general run_analysis tool that accepts any instruction and any document type, so agents need only one tool
  3. CSplit it into extract_data_points, summarize_content and verify_claim_against_source, each with its own output contract
  4. DKeep the tool and expand its description to list the three ways it can be used, with an example instruction for each
Show the answer and why
  • AAdd a final model call that rewrites every analyze_document result into one generic schema before the synthesis agent reads it

    Incorrect

    A second pass adds cost and latency and has to guess which kind of analysis produced the text in the first place.

  • BReplace it with a general run_analysis tool that accepts any instruction and any document type, so agents need only one tool

    Incorrect

    A more generic tool makes the contract even looser, which is the source of the problem.

  • CSplit it into extract_data_points, summarize_content and verify_claim_against_source, each with its own output contract

    Correct

    Purpose-specific tools with defined inputs and outputs make each call unambiguous and give downstream agents a structure they can rely on.

  • DKeep the tool and expand its description to list the three ways it can be used, with an example instruction for each

    Incorrect

    A better description helps Claude call it, but the output is still free text whose shape depends on the instruction.

When one generic tool serves several jobs with different outputs, split it into purpose-specific tools with explicit input and output contracts. Clear contracts help both tool selection and every consumer of the results.

Question 3 · choose 2

Your support agent's system prompt contains the line "If the customer mentions an order, call lookup_order first." Customers who write "I want to order a replacement charger" now trigger lookup_order with no order number, although the tools' descriptions are clear about what each one needs. Which TWO changes address the cause? (Choose TWO.)

  1. ARepeat the instruction in capital letters so Claude applies it more carefully
  2. BRewrite the keyword-triggered line so it states the situation in which an order lookup is needed rather than a word to react to
  3. CAdd more trigger words, such as "shipment" and "delivery", to the same line so the rule catches more cases
  4. DSet tool_choice to force lookup_order whenever the word "order" appears in the customer's message
  5. EMove the guidance on when to use lookup_order into its tool description, next to what the tool needs and returns
Show the answer and why
  • ARepeat the instruction in capital letters so Claude applies it more carefully

    Incorrect

    Emphasis makes Claude follow the keyword rule more strictly, not more sensibly.

  • BRewrite the keyword-triggered line so it states the situation in which an order lookup is needed rather than a word to react to

    Correct

    Keyword-sensitive instructions create unintended tool associations; describing the intent removes the false trigger.

  • CAdd more trigger words, such as "shipment" and "delivery", to the same line so the rule catches more cases

    Incorrect

    More keywords widen the same problem: more messages trigger a lookup whether or not one is needed.

  • DSet tool_choice to force lookup_order whenever the word "order" appears in the customer's message

    Incorrect

    Forcing the tool on a keyword hard-codes the misfire that the prompt line already causes.

  • EMove the guidance on when to use lookup_order into its tool description, next to what the tool needs and returns

    Correct

    Tool descriptions are where Claude weighs which tool fits, so the guidance belongs with the other details about the tool.

System prompt wording can override good tool descriptions. Review the prompt for keyword-triggered rules, replace them with intent-based criteria, and keep tool-selection guidance in the tool descriptions.

Question 4 · choose 1

Your support tools return customers and orders identified only by opaque 36-character UUIDs. Claude occasionally passes a slightly wrong UUID to the next call, or one from a different record. What change does Anthropic's tool-writing guidance suggest?

  1. AAsk Claude in the system prompt to copy UUIDs character by character
  2. BReturn longer UUIDs with a checksum so that mistakes are easier to detect afterwards
  3. CReturn meaningful names and simple identifiers alongside or instead of raw UUIDs
  4. DRemove identifiers from tool responses entirely
Show the answer and why
  • AAsk Claude in the system prompt to copy UUIDs character by character

    Incorrect

    This leans on care rather than giving the model a better identifier.

  • BReturn longer UUIDs with a checksum so that mistakes are easier to detect afterwards

    Incorrect

    Longer opaque IDs are harder for the model to carry correctly.

  • CReturn meaningful names and simple identifiers alongside or instead of raw UUIDs

    Correct

    Resolving cryptic IDs into interpretable values measurably reduces hallucinated identifiers.

  • DRemove identifiers from tool responses entirely

    Incorrect

    Later calls still need some way to refer to a record.

Tool responses should favor high-signal, interpretable fields; replacing opaque UUIDs with meaningful identifiers improves precision.

Question 5 · choose 1

Your search_threads tool returns full message threads with every internal ID. Most of the time the agent needs only the text, but sometimes it needs the thread IDs to fetch replies. Responses are using a lot of context. Which tool design fits?

  1. AAlways return the concise form and add a second tool that returns only IDs
  2. BA response_format parameter with "concise" and "detailed" options
  3. CAlways return the detailed form, since IDs might be needed later
  4. DReturn the full thread as an attached file instead of text
Show the answer and why
  • AAlways return the concise form and add a second tool that returns only IDs

    Incorrect

    A separate ID tool doubles calls for the cases that need both.

  • BA response_format parameter with "concise" and "detailed" options

    Correct

    The agent can ask for the compact form by default and the detailed form when it needs IDs for follow-up calls.

  • CAlways return the detailed form, since IDs might be needed later

    Incorrect

    Paying for IDs on every call wastes context most of the time.

  • DReturn the full thread as an attached file instead of text

    Incorrect

    Moving content to an attachment does not make it smaller for the model.

Let agents control response verbosity, for example with a response_format enum, so tools return only what each step needs.

Question 6 · choose 1

Your first prototype gives the agent a list_contacts tool that returns the whole address book of 40,000 contacts, and the agent reads through it to find one person. What does the tool-writing guidance recommend instead?

  1. AA paginated list_contacts that returns 1,000 contacts per page
  2. BA list_contacts tool that returns the contacts sorted by name
  3. CA larger context window so that the whole book fits at once
  4. DA search_contacts tool that returns only the matching contacts
Show the answer and why
  • AA paginated list_contacts that returns 1,000 contacts per page

    Incorrect

    Paging through the whole book still reads it all.

  • BA list_contacts tool that returns the contacts sorted by name

    Incorrect

    Sorting does not stop the agent from reading everything.

  • CA larger context window so that the whole book fits at once

    Incorrect

    Fitting irrelevant data is still wasting the agent's attention.

  • DA search_contacts tool that returns only the matching contacts

    Correct

    A targeted search spares the agent from reading irrelevant records token by token.

Build tools around how agents work: targeted searches rather than exhaustive listings that wrap an API endpoint.

Question 7 · choose 1

You have rewritten the descriptions of your internal MCP tools and want to know whether the agent now uses them better. Which approach does Anthropic's guidance recommend?

  1. ARun realistic tasks and study the transcripts and metrics
  2. BTest each tool with one trivial call in an empty sandbox
  3. CAsk the agent once whether the new descriptions are clearer
  4. DCount how many words each description has
Show the answer and why
  • ARun realistic tasks and study the transcripts and metrics

    Correct

    Evaluations grounded in real tasks, with transcripts and metrics, show where tools confuse the agent.

  • BTest each tool with one trivial call in an empty sandbox

    Incorrect

    Simplistic sandboxes do not stress-test tools the way real tasks do.

  • CAsk the agent once whether the new descriptions are clearer

    Incorrect

    One self-report is not a measurement of tool use.

  • DCount how many words each description has

    Incorrect

    Length does not measure whether the agent chooses and uses tools well.

Improve tools through evaluation: realistic tasks, verifiable outcomes, transcript review and metrics such as tool errors and call counts.

Question 8 · choose 1

Your Agent SDK custom tools include several read-only lookups that Claude often requests together in one turn, but they always run one after another. What lets the SDK run them in parallel?

  1. ASetting readOnlyHint: true in those tools' annotations
  2. BListing the tools in allowedTools
  3. CCombining the lookups into one tool with a list parameter
  4. DSetting disable_parallel_tool_use to false in every request
Show the answer and why
  • ASetting readOnlyHint: true in those tools' annotations

    Correct

    Custom tools run sequentially by default; readOnlyHint lets read-only tools run concurrently.

  • BListing the tools in allowedTools

    Incorrect

    Pre-approval removes prompts, not sequential execution.

  • CCombining the lookups into one tool with a list parameter

    Incorrect

    Possible, but it changes the interface instead of using the annotation built for this.

  • DSetting disable_parallel_tool_use to false in every request

    Incorrect

    Claude already requested the calls together; the SDK's execution is the bottleneck.

Tool annotations describe behavior; in the Agent SDK, readOnlyHint marks tools without side effects so they can execute in parallel. Keep annotations accurate.

Practise domain 2 →Practise all domains →