CCDV-F - Tools and MCPs (10.6% of the exam) - Section 8.1
Implement tools for Claude applications following established practice.
Published skill weight 4.4 percent. Covers tool use and function calling, configuration for interacting with an external system, writing tool descriptions, error handling, tool usage patterns including agentic harness dispatch, client-side versus server-side tools and approval patterns, and best practice for constructing a whole tool set rather than one tool.
tool use and function callingtool description writingagentic harness dispatchclient-side versus server-side toolsapproval patternstool set construction
Practice question for this objective
lock_openFree sampleTools and MCPsmedium
A team is adding stock lookups to a Claude assistant. The stock figures come from an internal REST service that is reachable only from inside the company network and requires a credential the company issues. An engineer proposes enabling one of the server-side built-in tools that Anthropic executes on its own infrastructure, arguing that this avoids writing any handler code. Which assessment of that proposal is correct?
AThe proposal works once the team supplies the service credential alongside the built-in tool definition, because the built-in tool then presents that credential when it reaches the internal stock endpoint.
BThe proposal fails, because built-in tools cannot be combined with custom tools in one request; the team must move every existing custom tool onto a server-side definition before stock lookups can work.
CThe proposal fails, because a server-side built-in tool runs on Anthropic's infrastructure and cannot reach a private endpoint; declare a custom tool whose handler the team's own code executes inside the network.check_circle Correct
DThe proposal works, because the assistant will describe the stock query in its request and the team's integration layer can intercept the built-in tool call and answer it from the internal service instead.
Only a client-side custom tool executes inside your network, so a private internal API needs a custom tool rather than a server-side built-in one. Built-in server-side tools are executed by the provider before the response returns, so their network position is the provider's, not yours. A custom tool is different in kind: the model emits a request, your own process performs the call from inside the boundary where the private service and its credential are reachable, and returns the result.
Why A is wrong: Tempting because attaching a credential is how most integrations gain access, but a credential does not create network reachability and the built-in tools do not accept an arbitrary internal endpoint as a target.
Why B is wrong: Tempting because it correctly rejects the proposal, but the stated reason is wrong: the two kinds of tool coexist in a request, and the real obstacle is where the tool executes.
Why C is correct: Correct: where the tool executes decides what it can reach, and only a client-side custom tool runs inside the network boundary where the stock service and its credential live.
Why D is wrong: Tempting because interception sounds like a thin shim, but a server-side tool is executed by the provider and never surfaces to the client as a call to answer, so there is nothing for the integration to intercept.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCDV-F bank for this domain.
Instruct the assistant in the system prompt to request one tool at a time and to wait for that result before asking for another, leaving the integration's single-result handling as it stands.
errorWhy it is wrong: Tempting because it would reduce how often two blocks appear, but it leaves the integration unable to answer a multi-block turn correctly, so the failure persists whenever the model batches two lookups anyway.
Append a tool result block carrying the same tool use identifier with an empty body, then send the conversation back to the model and continue the loop as though the call had returned nothing.
errorWhy it is wrong: Tempting because the loop does continue and the identifier is answered, but an empty result is indistinguishable from a genuine empty lookup, so the model reports the carrier as having no record rather than as unreachable.
The input schemas are under-specified, so the model cannot work out which arguments belong to which of the two tools when it assembles a call.
errorWhy it is wrong: Tempting because a loose schema is a common cause of tool defects. It is wrong here because the measured evidence says every call is well formed and accepted, so the arguments are not where the failure sits.