CCDV-F - Tools and MCPs - 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

Free 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. 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.

See more CCDV-F practice questions, answers explained.

More in this domain

Back to all Tools and MCPs objectives, or the CCDV-F cert hub.

Examworthy is not affiliated with or endorsed by Anthropic. Original, blueprint-aligned practice material only.