Practice — CCDV-F Domain 8: Tools and MCPs (10.6%)
9 scenario-based MCQs. Answer key + explanations at the bottom.
Q1
You are running an agent loop and the latest response arrives with stop_reason: "tool_use" containing two tool_use blocks — get_weather for Berlin and get_weather for Tokyo. Which handling is correct?
A. Run both tools, then append the assistant turn plus one user turn holding both tool_result blocks
B. Run only the first tool and return its result; Claude will re-issue the second call on the next turn
C. Run both tools and reply with a plain-text user message that summarizes the two outputs together
D. Run both tools but send each tool_result in its own API request so that ordering is preserved
Q2
A support agent defines search_tickets and search_orders. In evals, Claude calls search_orders for ticket-related queries about 30% of the time. Which change is most likely to fix tool selection?
A. Rename the two tools to shorter, more distinctive single-word names
B. Set tool_choice to any so Claude is always forced to call one of the two tools
C. Move search_tickets earlier in the tools array so it receives higher priority
D. Rewrite both descriptions to state when to use each tool and when not to
Q3
A team adds Anthropic's built-in web search tool and a custom lookup_inventory tool to the same request. Which statement correctly describes who executes what?
A. Both tools execute on Anthropic's servers once they are declared in the request's tools array
B. Both tools come back as tool_use blocks that the team's own application code must execute and answer with tool_result blocks in the next user turn
C. Web search runs server-side on Anthropic's infrastructure; lookup_inventory returns a tool_use block the team's code executes and returns
D. Web search must be executed client-side by the team; only custom tools run on Anthropic's infrastructure
Q4
You are building an MCP server whose delete_project tool must obtain explicit user confirmation before acting, and the flow must work identically in any MCP-aware client. Which protocol mechanism is designed for this?
A. Sampling — the server asks the client to run an LLM call that verifies the user's intent
B. Elicitation — the server asks the client to collect the user's input or confirmation
C. A notifications/tools/list_changed event that pauses the client until it is acknowledged
D. Exposing delete_project as a resource instead, since resources are application-controlled
Q5
An internal MCP server offers: (1) an execute_query action the model can invoke mid-conversation, (2) read-only schema documentation the host application attaches as context, and (3) parameterized report templates users pick from a menu. Which primitive mapping is correct?
A. (1) tool, (2) resource, (3) prompt B. (1) tool, (2) prompt, (3) resource C. (1) resource, (2) tool, (3) prompt D. (1) prompt, (2) resource, (3) tool
Q6
Your Postgres MCP server currently runs as a stdio subprocess on each analyst's laptop. The platform team wants one centrally hosted deployment the whole org connects to with per-user auth and no local installs. Which approach fits?
A. Keep stdio and distribute the server binary through the internal package registry B. SSE, since it remains the standard transport for long-lived hosted MCP services C. stdio tunneled over SSH so the subprocess actually runs on the central host D. Streamable HTTP with OAuth — the current standard for remote multi-client servers
Q7
While debugging a Python stdio MCP server, a developer adds print() statements inside the tool handlers. Afterward Claude Desktop can no longer talk to the server and reports JSON parse errors. What is the root cause?
A. The server never declared the logging capability during initialization, so the client rejects its output
B. print() writes to stdout — the stdio transport's JSON-RPC wire; diagnostics belong on stderr
C. JSON-RPC over stdio requires Content-Length framing, which the added print() calls break
D. The protocol version negotiated at initialize does not support log messages from servers
Q8
A design-ops team wants Claude to apply their brand guidelines whenever someone requests a slide deck: a few pages of instructions, reference templates, and a helper script — no external service to call. It must be shared across the org's repos with minimal context cost when unused. Which mechanism fits best?
A. A custom client-side tool that returns the guideline text whenever Claude calls it
B. An MCP server exposing the guidelines as tools, hosted centrally over Streamable HTTP
C. A Skill — SKILL.md instructions with bundled templates and scripts, loaded on demand
D. An MCP prompt template that users invoke from the menu whenever they start a deck
Q9
A résumé-parsing pipeline defines three tools (extract_resume, search_candidates, send_email) and must always emit JSON matching extract_resume's input_schema, because downstream code breaks on prose. Which configuration is most reliable?
A. Keep tool_choice at auto and instruct "respond only with valid JSON" in the system prompt
B. Set tool_choice to any so Claude must call one of the defined tools rather than answer in text
C. Prefill the assistant turn with { so the completion is forced to begin as JSON output
D. Force tool_choice to {"type": "tool", "name": "extract_resume"} and read the block's input
Answers
Q1: A. Claude can emit multiple tool_use blocks in one turn; the contract is to execute them (in parallel for the latency win), append the assistant turn, and return all tool_result blocks — each tagged with its tool_use_id — in a single user turn. (B) drops a requested call and stalls the loop. (C) breaks the protocol: results must be tool_result blocks tied to IDs, not prose. (D) forgets the API is stateless — splitting results across requests produces malformed conversations, and parallel calls need no ordering.
Q2: D. Claude decides whether and which tool to call based on the description, not the name — so the fix is descriptions that specify when to use AND when not to use each tool, then re-running the eval queries to verify. Renaming (A) tweaks the least influential signal. tool_choice: any (B) forces some call but does nothing to pick the right one. Array ordering (C) is not a documented selection lever.
Q3: C. Built-in tools like web search and code execution run server-side on Anthropic's infrastructure — you get the capability without hosting execution — while custom tools are client-side: Claude returns a tool_use block and your application must execute it and send back a tool_result. (A) and (B) each apply one execution model to both tool kinds; (D) inverts the split entirely.
Q4: B. Elicitation (elicitation/create) is the client primitive that lets a server ask the user for input or confirmation through whatever UI the host provides, keeping the flow client-agnostic. Sampling (A) requests an LLM call, which is not user consent and shouldn't gate a destructive action. (C) is a capability-refresh notification, not a confirmation flow. (D) misuses the primitive taxonomy — resources are read-only data, and rebadging a destructive action doesn't add a consent step.
Q5: A. Tools are model-controlled actions with side effects (execute_query), resources are application-controlled read-only data attached as context (schema docs), and prompts are user-controlled templates surfaced in a menu (report templates). The "who decides" mapping — model/tools, application/resources, user/prompts — is exactly what (B), (C), and (D) scramble.
Q6: D. Streamable HTTP is the current standard transport for remote, centrally hosted, multi-client MCP servers, and remote MCP auth is OAuth 2.1 — matching the per-user auth requirement. SSE (B) is the tempting runner-up but is legacy, superseded by Streamable HTTP. (A) keeps a local subprocess per user, which is exactly what the team wants to eliminate. (C) is a transport hack, not a protocol-supported remote deployment with auth.
Q7: B. With stdio transport, stdout is the JSON-RPC wire; any stray print() interleaves text with protocol frames and corrupts parsing, which is why server logs must go to stderr. (A) and (D) are red herrings — capability negotiation governs protocol log messages, not raw stdout writes. (C) invents framing that stdio MCP doesn't use; messages are framed line-by-line, and the failure comes from polluting the stream, not from missing headers.
Q8: C. This is reusable know-how (instructions + templates + a script), no external system to integrate — the Skill slot in the tradeoff matrix. Skills are lazy: only the description sits in context until triggered, and they can bundle files and scripts, and they're shareable via the repo's .claude/skills/. A custom tool (A) models an action, not know-how, and puts schemas in every request. An MCP server (B) buys cross-surface integration plumbing with nothing external to integrate. An MCP prompt (D) is user-invoked and can't bundle template files or scripts — here the model should detect deck requests on its own.
Q9: D. Forcing a specific tool with tool_choice: {type: "tool", name: "extract_resume"} is the most reliable structured-output technique — Claude must emit a tool_use block whose input matches the schema. (B) is the runner-up but only guarantees some tool call; with three tools defined, Claude may pick search_candidates or send_email. (A) is the least reliable, prompt-only option. (C) forces JSON-ish output but enforces no schema, so fields can still be missing or malformed.