CCAR-F - Tool Design & MCP Integration (18% of the exam) - Section 2.1
Design effective tool interfaces with clear descriptions and boundaries.
Tool descriptions are the primary mechanism a model uses to select a tool, so minimal or overlapping descriptions cause misrouting between similar tools. A good description carries input formats, example queries, edge cases and an explicit boundary against its nearest alternative. Candidates should rename and re-scope overlapping tools, split a generic tool into purpose-specific ones with defined input and output contracts, and audit system prompts for keyword-sensitive wording that overrides a good description.
tool description qualityoverlapping tool misroutinginput formats and boundary explanationssplitting generic toolskeyword-sensitive system prompts
The Resolution Desk team added a second identity tool, find_account, alongside get_customer on their Customer Support Resolution Agent. The get_customer description says it retrieves a customer record by account identifier, and the find_account description says it retrieves customer details by email address or phone number. Across 2,000 contacts the agent calls find_account with an account identifier in 19 percent of cases, receives a result with no matching record, and then tells the customer that the account system is down rather than trying get_customer. Which change most effectively addresses the logged behaviour?
AAdd a line to the system prompt telling the agent to prefer get_customer whenever an account identifier appears anywhere in the conversation.
BRewrite both descriptions so each names the identifier type it accepts, the situations it is intended for, and the sibling tool to call instead when the input is of the other type.check_circle Correct
CAdd three worked examples to the system prompt showing an email address routed to find_account and an account identifier routed to get_customer.
DWiden the find_account input schema to accept an account identifier as a third field so either tool can resolve the customer record.
Overlapping tools are routed correctly when each description names its accepted input and the boundary against its sibling. Tool selection happens from the tool definitions themselves, so two descriptions that both read as customer lookup give the model no basis for discriminating. Naming the accepted identifier type and pointing at the sibling tool moves the routing rule into the place the model consults at call time, rather than leaving it in prose that competes with everything else in the context.
Why A is wrong: Tempting because the routing rule is easy to write and costs nothing to ship, but it leaves both tool descriptions ambiguous at the point of selection and makes correct routing a probabilistic outcome of prompt attention.
Why B is correct: Correct, because the description is what the model reads when it chooses a tool, so stating the accepted input and the explicit boundary against the sibling tool removes the ambiguity that produces the misroute.
Why C is wrong: Examples do lift routing accuracy a little, which makes them attractive, but the root cause is a thin and overlapping pair of descriptions, so the agent still has to infer the boundary rather than read it.
Why D is wrong: Plausible because it stops the failed lookups, yet it increases the overlap between the two tools rather than reducing it and leaves the agent with no principled basis for choosing between them.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-F bank for this domain.
Expand the single description into a glossary listing all seven operation values with a sentence of meaning against each of them.
errorWhy it is wrong: Attractive because it does add the missing detail, but it buries seven behaviours in one definition the model must read as a block, so the selection signal for a low-risk action stays adjacent to a destructive one.
Schema validation can now reject an operation the customer did not ask for, because each tool declares a narrower set of accepted values than the shared operation argument did before the split was made.
errorWhy it is wrong: Validation does check a narrower schema now, but it has no knowledge of what the customer asked for, so it cannot reject a semantically wrong but well formed call; the improvement happened before validation runs.
Name the tool in the system prompt with a sentence saying that it exists and should be used whenever a customer is arranging a return of goods.
errorWhy it is wrong: Tempting because usage would rise immediately, but it patches the gap in the prompt while the definition the model reads at selection time still describes an internal service rather than a customer outcome.