Tool Use and Function Calling for the CCDV-F Exam

What tool use actually is

Tool use, also called function calling, is the mechanism that lets Claude reach beyond generating text and take an action in the world: query a database, call an API, read a file, send a request. On the Claude Certified Developer - Foundations (CCDV-F) exam this is the root knowledge point of Domain 8, because every later topic about MCP servers, custom tools, and agentic customization assumes you already understand this one contract.

The contract has two halves. First, you declare each tool so Claude knows it exists and how to call it. Second, when Claude decides a tool is warranted, it hands the request back to your code to run. Getting those two halves straight is the whole of this knowledge point, and it is where a surprising number of candidates trip.

How a tool is declared

A tool declaration has exactly three parts, and each carries real weight. The name identifies the tool so Claude can name it in a request. The description is a natural-language statement of what the tool does and when to use it, and this is what Claude reads to decide whether the tool is the right one for the current step. The input schema is a JSON schema describing the arguments the tool accepts, including their types and which are required.

None of these fields is decorative. A vague description means Claude cannot tell when the tool applies, so it either skips a tool it should have used or calls one it should not have. The input schema is what constrains the arguments Claude may emit: with a schema, the model is guided to produce a city string and a units enum; without one, the arguments are unconstrained and the model can invent malformed or unexpected shapes. Declaring the schema is therefore not optional polish, it is what makes the call reliable.

The request-execute-return loop

Here is the single most important idea on this page, and the one the exam tests hardest. When Claude determines a tool is needed, it does not run the tool. It emits a tool_use block into its response: a structured block naming the tool and supplying an input object with the arguments. That block is a request, not an action. Your harness reads the block, runs the actual function in your environment, and sends the outcome back to Claude as a tool_result block on the next turn.

This division of labour is deliberate. The model supplies judgement about which tool to call and with what arguments; your code supplies the execution, the credentials, and the network access. Because function calling works this way, Claude can act on external systems from inside the agentic loop without ever holding those systems' secrets or running code directly. Understanding this request-execute-return cycle is what unlocks tool error handling and usage patterns, where the same loop is extended with structured errors and approval gates.

Why function calling matters for agents

A single text response answers one question. An agent pursues an open-ended goal, and it does that by looping through tool calls: request a tool, get a result, reason about it, request the next tool, and so on until the goal is met. Function calling is the primitive that makes each of those steps possible. Without declared tools, Claude can only describe what it would do; with them, it can drive real work forward one call at a time.

This is why the same tool contract underlies so much of Domain 8. When you later decide between built-in tools versus custom tools, or you author an MCP server to expose reusable tools, you are still declaring name, description, and schema, and Claude is still requesting calls for your harness to run. The packaging changes; the underlying request-execute-return contract does not.

The traps the exam sets

Two misreadings account for most wrong answers on this knowledge point, and both come straight from misunderstanding the contract above.

The first trap is assuming the model executes tools itself. A scenario might describe a developer who defines a send_email tool and is surprised that no email is sent, or who worries that Claude will run arbitrary code. The correction is always the same: Claude only emits a request. If nothing happens after a tool_use block, it is because the harness did not run the function and return a tool_result. The model cannot send the email, touch the database, or call the API on its own.

The second trap is omitting the input schema so arguments are unconstrained. Without a schema, Claude has no contract for the arguments and can produce shapes your function cannot parse, missing required fields or wrong types. The exam frames this as a reliability problem: a tool that works sometimes and fails unpredictably usually has a missing or loose schema. Defining the schema is what makes the arguments predictable.

Common misreadings to avoid

How this is tested on the exam

Domain 8 questions on this knowledge point are usually diagnostic. A scenario describes a tool that is defined but never seems to do anything, or a tool whose arguments arrive malformed, and you must name the cause. The correct answer traces back to the two facts here: Claude requests calls rather than executing them, and a defined input schema is what constrains the arguments.

Because this is an understand-level knowledge point, you are expected to explain the contract precisely rather than design a novel system. Know that a tool is a name plus a description plus a schema, that Claude emits tool_use to request a call, and that your harness runs it and returns a tool_result. Every other Domain 8 topic, from tool error handling to MCP servers, stands on this foundation.