CCDV-F Practice Questions: Tools and MCPs Domain

Correct answer (A): The scenario explicitly requires a shared MCP service reachable by clients on separate hosts. Socket-based communication is better aligned with networked or service-style deployments. Stdio is commonly suited to local process integration where a client launches or communicates with a local subprocess.

Why the other options are wrong:
- Option B: Stdio fits local process integration, but the requirements reject local child-process launch and require remote access.
- Option C: A Skill can package instructions or procedures, but it does not provide a networked executable inventory service.
- Option D: Copying the tool into each client conflicts with the shared-service requirement and increases maintenance duplication.

Correct answer (A): Server-side tool placement is appropriate when execution requires centralized credentials, controlled infrastructure, or access to backend-only networks. The server can enforce business logic and keep service credentials out of desktop clients while still exposing a controlled tool interface to Claude.

Why the other options are wrong:
- Option B: Client-side tools fit user-local context, but distributing centralized service credentials to desktops conflicts with the stated credential and network constraints.
- Option C: A URL in a description does not implement controlled execution, credential handling, or backend network access.
- Option D: Pasting credentials into chat is not an appropriate tool placement strategy and does not centralize execution authority.

Correct answer (A): Skills are useful for packaging reusable instructions, workflows, or domain procedures. The scenario explicitly says there is no external API call or shared data source to expose. An MCP server is more appropriate for reusable tools and resources across clients, but here the reusable asset is procedural guidance rather than an executable integration.

Why the other options are wrong:
- Option B: An MCP server would add integration overhead for text that is procedural guidance, not an executable action or shared data source.
- Option C: Duplicating a custom tool in each assistant adds maintenance burden and misuses tools for static procedure delivery.
- Option D: A state-changing tool is inappropriate because the checklist is not an executable operation and has no external state change.

Correct answer (A): The trace shows the tool name matches, but the arguments fail schema validation because `customer_id` is required and only `email` was supplied. Tool failures can originate from schema or argument mismatches before any external API call occurs.

Why the other options are wrong:
- Option B: The harness stopped at validation, so the evidence does not show that the external API was called or unavailable.
- Option C: The trace points to a concrete argument/schema mismatch, not a general model capability issue.
- Option D: The artifact does not describe MCP transport, and validation errors are not specific to socket-based communication.

Correct answer (A): Tool implementations should return structured, recoverable errors such as not_found, invalid arguments, permission denials, or upstream failures. A safe structured error gives Claude enough information to ask for clarification or explain the issue without exposing opaque internal details.

Why the other options are wrong:
- Option B: A stack trace may help developers, but it is opaque to users and can derail Claude's recovery behavior.
- Option C: Indefinite retries do not address an unknown identifier and can waste resources or block the conversation.
- Option D: Suppressing the tool result removes the evidence Claude needs and encourages unsupported responses.

Correct answer (A): An MCP tool represents an executable capability such as querying or updating an external system. Because `submit_refund` calls a billing API and creates a transaction, it should be exposed as an MCP tool, while the policy document would fit a resource and the explanation template would fit a prompt.

Why the other options are wrong:
- Option B: An MCP resource is appropriate for readable data or context, not for executing a refund transaction.
- Option C: An MCP prompt is a reusable template or interaction pattern, not the API action that creates the refund.
- Option D: MCP can expose executable tools; the issue is to classify the API action correctly and control execution appropriately.

Correct answer (A): A focused tool set with non-overlapping purposes helps Claude select the right tool more reliably. The artifact shows several broad, overlapping tools with vague descriptions. Narrowing or consolidating the set and making the remaining names, descriptions, and schemas distinct directly addresses the selection ambiguity.

Why the other options are wrong:
- Option B: A prompt instruction may help slightly, but it leaves the overlapping vague tools that are causing ambiguous selection.
- Option C: Adding more tools increases the selection space and is likely to worsen ambiguity rather than improve reliability.
- Option D: A prompt template cannot replace executable access to CRM data when external retrieval is required.

Correct answer (A): Claude can request a named tool with structured arguments, but the application, agent harness, or MCP server is responsible for executing the external operation and sending the tool result back to Claude. Defining a tool alone does not perform the side effect.

Why the other options are wrong:
- Option B: A clearer description may improve tool selection, but it will not execute the requested external operation.
- Option C: Claude does not directly execute arbitrary external services; execution must be handled by the integration layer.
- Option D: Exposing an endpoint in the final response is not the tool-use loop and would not perform the invoice action safely.

Correct answer (A): When required information is missing or invalid, the integration should not fabricate arguments. A structured, recoverable error gives Claude enough information to ask the user for the missing origin and a valid date. This preserves the tool contract and helps recovery without unsafe assumptions.

Why the other options are wrong:
- Option B: Guessing the origin may appear convenient, but it fabricates a required argument and can produce incorrect quotes.
- Option C: Passing invalid partial arguments pushes a known validation problem downstream and may create unpredictable API behavior.
- Option D: Disabling validation weakens the tool contract and does not ensure the booking API receives usable values.

Correct answer (A): When a built-in tool already satisfies the requirement, it should generally be preferred because it reduces custom implementation and maintenance burden. MCP servers and custom tools are valuable when they provide needed integration boundaries, reuse, or capabilities not already covered, but the scenario says the built-in tool is available and sufficient.

Why the other options are wrong:
- Option B: An MCP wrapper adds operational overhead without a stated reuse or capability gap beyond the built-in tool.
- Option C: Custom HTTP tooling is unnecessary when the approved built-in capability already satisfies the requirement.
- Option D: A Skill can package instructions, but it is not a substitute for an executable retrieval capability.