Tool Design & MCP Integration

The Resolution Desk team adds a second MCP tool, find_account, alongside the existing get_customer on their Customer Support Resolution Agent. get_customer is described as retrieving a customer record by identifier, and find_account is described as retrieving an account record by identifier. Both take a single string argument. Across 800 sessions the agent calls find_account in roughly half of the identity checks the team intended to route to get_customer, with no pattern the team can predict from the transcripts. Which statement best explains that split?

• AThe two tools return records of different shapes, so the agent deliberately alternates between them across sessions in order to compare the two results before it answers the customer's opening question.
• BThe MCP server registers tools in the order they are listed in the project .mcp.json file, and the model is required to select the earlier registration whenever two tools accept an argument of the same type.
• CIdentical input schemas make validation reject one of the two calls, after which the harness automatically retries the request against the sibling tool, which is what produces an even split of calls across the sessions.
• DTool selection is driven by the tool name and the description text, so two descriptions stating the same capability in different words give the model no discriminating signal, and the choice then varies with the wording of each customer's message.check_circle Correct

Why A is wrong: Tempting because the tools genuinely do return different record shapes, but the agent has no comparison behaviour of that kind; it selects one tool per intent, and nothing in the loop asks it to sample alternatives.

Why B is wrong: Registration order is real, but it carries no selection precedence of this sort, and a rule like this would produce a consistent bias rather than the unpredictable half-and-half split observed.

Why C is wrong: Plausible if you assume schemas are compared across tools, but validation checks a call against its own tool's schema only, and there is no automatic retry that reroutes a call to a different tool.

Why D is correct: Correct. The description is the routing surface, and two overlapping descriptions leave the selection to incidental phrasing, which is exactly the unpredictable split the team measured.

A DocExtract subagent specialising in contract clause extraction is dispatched with allowedTools of Read, Grep and extract_contract_terms, and its system prompt additionally states that it must not work on invoice documents. Across 2,000 dispatches, telemetry records no calls at all to extract_invoice_fields, and 14 dispatches in which the subagent used Read to open a scanned invoice and reported figures taken from it. An architect wants to know which control produced which half of that result. Which statement is correct?

• ABoth results follow from the system prompt, because allowedTools is advisory guidance and a model can still request any tool that has been declared elsewhere in the project configuration.
• BBoth results follow from allowedTools, because a prompt instruction cannot influence tool behaviour at all once the available tool list has been narrowed at dispatch time.
• CThe absence of invoice tool calls follows from the prompt, and the 14 Read openings show that allowedTools grants access at the level of files and directories rather than at the level of tools.
• DThe absence of invoice tool calls follows from allowedTools, which never presented that tool, while the 14 Read openings show that a prompt instruction constrains behaviour only probabilistically.check_circle Correct

Why A is wrong: Tempting because much agent configuration genuinely is guidance rather than enforcement, so treating the tool list the same way is a consistent mistake. It is wrong because allowedTools determines which tools are presented at all, which is why the invoice tool count is exactly zero.

Why B is wrong: Tempting because it correctly credits allowedTools for the zero count and sounds appropriately rigorous. It is wrong because the prompt clearly did shape behaviour: Read stayed available throughout, yet the invoice instruction held in 1,986 of 2,000 dispatches.

Why C is wrong: Tempting because Read does touch files, so a file-scoped reading of allowedTools feels coherent. It is wrong because allowedTools names tools rather than paths, and attributing the zero invoice count to the prompt misplaces the only deterministic control in the design.

Why D is correct: Correct because it separates the two controls by their nature: the tool list is a hard boundary that produced a deterministic zero, and the prompt is a strong but leaky influence over a tool the subagent legitimately holds.

DocExtract must call extract_invoice_fields at least once per document, so an engineer sets tool_choice to that named tool. Rather than setting it on the opening request only, the harness applies it to every request in the agentic loop, including those that follow a tool result. Extraction sessions now run until the harness cuts them off at its per-session call ceiling, and no session ever produces the final summary message the downstream system consumes. Which mechanism explains that outcome?

• AForcing the named tool on every request makes each response come back with stop_reason tool_use, so the model can never close its turn with a text answer and the loop is left with no natural stopping point.check_circle Correct
• BThe accumulated tool result blocks grow the conversation until the context window is exhausted, and the loop halts only once the API begins rejecting the oversized request as too long.
• CA named tool_choice value suppresses parallel tool use, so the model issues one call per request and simply needs more iterations than the configured ceiling permits.
• DIdentical repeated tool calls are collapsed by the API into a single execution, so the loop replays the same request unchanged and only the ceiling can interrupt it.

Why A is correct: Correct because a normal loop ends when the model returns end_turn instead of a tool call, and a forced named tool removes that option on every iteration. The ceiling then becomes the only exit, which is precisely the symptom reported.

Why B is wrong: Tempting because long extraction sessions really do accumulate large tool results and context pressure is a real production concern. It is wrong because the sessions stop at the configured call ceiling, not at a size limit, and the missing summary is a termination fault rather than a capacity fault.

Why C is wrong: Tempting because forcing a named tool does yield one call per response, so the reasoning starts from a true observation. It is wrong because raising the ceiling would not help: every additional iteration would also be forced into a tool call and the summary would still never arrive.

Why D is wrong: Tempting because repeated identical calls do appear in the logs of such a session, which makes deduplication sound like a plausible cause. It is wrong because no such collapsing behaviour exists; the repetition is a symptom of the forced setting, not a mechanism of its own.

An engineer on a developer productivity team adds a documentation-search MCP server to her user-scoped configuration so that it follows her across the nine repositories she works in, rather than adding it to any one repository. Two weeks later a teammate reports that the same server is missing from his checkout of the shared platform repository, and a headless Claude Code run on the build agent also reports the server's tools as unavailable. What does the user-scoped registration guarantee?

• AIt registers the server for her own sessions across her projects on that machine, so nothing in the repository carries it to a teammate's checkout or to the build agent's environment.check_circle Correct
• BIt makes the server available to every account on that machine, including the service account the build agent runs under, so the headless failure is a missing credential rather than anything to do with the scope she chose.
• CIt writes the definition into each repository's .mcp.json the next time she opens that project, so her teammate will pick the server up as soon as he pulls the platform repository again.
• DIt applies in projects that carry no committed server definitions, so the server is shadowed in any repository that already has a .mcp.json and that shadowing is what her teammate is seeing.

Why A is correct: Correct: user scope trades sharing for convenience, giving one developer the server everywhere she works while leaving the repository and every other environment untouched.

Why B is wrong: Tempting because a missing credential is a common cause of a headless-only failure, but user scope is bound to one user's configuration and does not extend to other accounts on the machine.

Why C is wrong: Tempting because it would explain how a personal choice reaches the team, but user-scoped entries are kept in her own configuration and are never written back into a repository.

Why D is wrong: Tempting because scopes really are layered, but a project file does not suppress a user-scoped server; the two contribute together, and her teammate simply has no such registration of his own.