Claude Certification Blog
Claude tool use and structured output: current exam scope
Claude tool use and structured output are separate contracts: tool use has client- and server-execution paths, while structured outputs add schema guarantees only through JSON output or strict tool use, and neither proves that the values are true or authorized.
Claude tool use and structured output rest on a contract between the model, the API and an executor. For a client tool, Claude emits a structured request and your application decides whether and how to run it. For a server tool, Anthropic executes it. Structured outputs are two separate schema features: JSON output constrains the final response, while strict tool use constrains tool names and inputs. None of those mechanisms validates factual meaning, authorization or business rules.
That corrects two shortcuts: “Claude never executes” ignores server tools, and “a schema guarantees its arguments” holds only with strict validation enabled on a supported schema.
Claude tool use and structured output: the current CCDV-F and CCAR-F scope
The July 2026 guides split this topic across domains and skill or task statements. The weights below are approximate shares of scored items, not guaranteed question counts.
| Exam | Published location | Published weight | Relevant boundary |
|---|---|---|---|
| CCDV-F | Domain 8 · Tools and MCPs | 10.6% domain; 4.4% Tool Implementation | Tool use/function calling, descriptions, errors, execution patterns, approvals and tool-set design. |
| CCDV-F | Domain 6 · Prompt and Context Engineering | 2.6% Output Handling subsection | Structured-output patterns, response validation, defensive parsing and confident-output skepticism. |
| CCAR-F | Domain 2 · Tool Design & MCP Integration | 18% | Tool interfaces, error responses, tool choice, access scope, MCP integration and built-in tools. |
| CCAR-F | Domain 4 · Prompt Engineering & Structured Output | 20% | Strict schemas, tool choice, optional fields, semantic validation and retry feedback. |
Read the current source for CCDV-F or CCAR-F. The CCAR-F guide explicitly names stop reasons, tool-choice modes, strict schemas, nullable fields and validation feedback; “learn the concept, never the fields” is not an accurate preparation rule.
Where tools execute
Anthropic's current tool-use overview separates tools primarily by execution location. “Anthropic publishes the schema” does not mean Anthropic runs the code: Bash, text editor, computer and browser are Anthropic-schema client tools that the application still executes.
| Tool category | Who supplies the schema | Who executes | Application responsibility |
|---|---|---|---|
| User-defined client tool | Your application | Your application | Return one tool_result for each tool_use ID |
| Anthropic-schema client tool | Anthropic | Your application | Return tool_result; some toolsets have extra result fields |
| Server tool | Anthropic | Anthropic infrastructure | Result normally arrives in the response; handle pause or a mixed unfinished call when present |
Server tools normally execute and return results inside the response. Long-running server loops can pause, and a response mixing server and client calls can leave a server call unfinished until client results come back. The server-tools guide documents those cases.
The client-tool round trip
Declare tools with the request. Provide each name, description and input schema, plus any supported controls such as strict validation.
Read every tool request. A client-tool response can contain text and one or more tool_use blocks; stop_reason is tool_use.
Authorize and execute in your code. Validate policy and side effects, then run independent calls in parallel or ordered calls sequentially.
Return every result in one continuation. Put tool_result blocks first, match each tool_use_id, mark real failures, and continue the conversation.
Use the response's machine-readable blocks and stop reason, not narration such as “I will check.” For manual loops, the current result-handling guide requires the result message immediately after the call, all result blocks before any text, and a matching result for each client tool-use ID.
Design the whole tool contract
A user-defined client tool includes a name, detailed description and input schema; complex tools can also use validated input examples. Anthropic calls the description the most important performance factor, but it is not the only input. Meaningful names, a schema that represents real optionality, examples and the surrounding instructions all affect the call.
The current tool-definition guidance recommends grouping related operations and meaningful namespacing for a larger surface. Split tools when operations or permissions are unrelated; consolidate when a clear action field expresses the contract better. Avoid the absolutes of “one tool per action” and “one generic tool for everything.”
Control whether a tool runs
The default automatic mode lets Claude call a tool or answer directly. Other modes can require some tool, require one named tool or disallow tools. Choose the least force the task needs, and confirm current compatibility.
Tool choice never replaces authorization. Before a client tool causes a side effect, your application must enforce identity, permissions, policy and prerequisites outside the model's prose.
What structured outputs guarantee
Anthropic's structured-output documentation defines two complementary features. JSON output constrains the final response; strict tool use constrains the selected tool name and its input.
| Mechanism | Structural guarantee | Use it when |
|---|---|---|
| Prompt-only format request | No structural guarantee | Flexible prose or best-effort formatting where malformed output is tolerable |
| JSON output | Final response conforms to the supported JSON Schema | A schema-shaped response for downstream parsing |
| Strict tool use | Tool name and input conform to the supported tool schema | Type-safe arguments for a client or eligible Anthropic-provided tool |
Schema-valid is not semantically valid
Strict mode can guarantee supported-schema conformance while a value is factually wrong, unauthorized, inconsistent with another field or absent from the source. Use required fields for information that must exist, and optional or nullable fields when absence is legitimate; then validate meaning with a separate rule or reviewer. See how to evaluate Claude output.
Strict conformance itself requires strict mode. A plain input schema describes expected arguments but does not prevent missing or mistyped fields. The strict-tool documentation explains the supported-schema guarantee and current limitations.
Results, errors and parallel calls
The wrapper must distinguish valid data, a valid empty result and a failure. It must also preserve call IDs, execution order and trust boundaries, even when the model chose the correct tool.
| Case | Contract signal | Handler responsibility |
|---|---|---|
| Successful result with data | Normal tool_result content | Let Claude use the returned data; keep untrusted source content inside the result block. |
| Successful query with no matches | Normal result whose contract explicitly represents an empty set | Do not relabel a valid no-match as an execution failure. |
| Execution or permission failure | tool_result with is_error set and concise actionable content | State what failed, whether retry is appropriate and what information or authority is needed. |
| Several independent calls | Multiple tool_use blocks in one assistant response | Return one result per ID together; parallelize only when side effects and dependencies allow. |
| Dependent or stateful calls | Later input or safety depends on an earlier result | Execute sequentially and report skipped calls as errors when an earlier dependency fails. |
By default, one response can contain several calls. Anthropic's parallel-tool guide says independent reads can run concurrently, while calls with side effects, shared state or dependencies may need sequencing. Return all results together and explicitly mark a skipped dependent call as an error.
Tool results may carry web pages, email, uploads or third-party content. Keep it in tool-result blocks; never promote embedded instructions into system or user instructions, the boundary examined as prompt injection and guardrails. Tool use also underpins agents, but workflow versus agent architecture is separate, as is what a retry knows. Checked against the official CCDV-F and CCAR-F exam guides (version 1.0, July 2026) and Anthropic's tool-use documentation on 17 September 2026.
Key takeaways
- Execution location comes first. Applications run client tools; Anthropic runs server tools, with special continuation cases for pauses and mixed calls.
- A schema alone is not strict. Enable strict tool use for guaranteed supported-schema conformance of tool names and inputs.
- Tool definition is a whole contract. Description matters most, alongside name, schema, examples, instructions, permissions and output design.
- Empty and failed are different. Use a normal empty result for a valid no-match and an explicit error signal for a real failure.
- Structural validity is not truth or authorization. Validate semantics and enforce side effects outside the model response.
Practise the current contract, not a stale diagram
Learn the blueprint for your track, then trace execution, strictness, result IDs, errors and semantic validation through realistic scenarios. The Claude certification study guide shows how to build that repair loop.
See the current CCDV-F blueprintQuestions
Frequently asked
The follow-up questions people search next.
Does the Claude certification exam test function calling?
Yes, under tool use. The current CCDV-F guide places Tool Implementation at 4.4% inside the 10.6% Tools and MCPs domain. CCAR-F covers the tool contract in its 18% Tool Design & MCP Integration domain and strict structured output in its separate 20% Prompt Engineering & Structured Output domain. All weights are approximate.
How much of CCDV-F is tool use?
The July 2026 guide gives Tools and MCPs a 10.6% domain weight and Tool Implementation a 4.4% skill weight. Structured output also appears in the 2.6% Output Handling subsection of Prompt and Context Engineering. Do not add those figures into an item count; they describe different scopes.
What is the main purpose of a JSON schema when working with Claude tools?
It defines the tool's input contract, so Claude knows which arguments to supply and in what shape. It constrains shape, not truth: a schema-valid value can still be wrong, unauthorized or missing from the source, so validate meaning separately.
Which tool_choice parameter forces Claude to use a specific tool?
The tool_choice request parameter. Setting it to {"type": "tool", "name": "<tool name>"} forces that named tool; {"type": "any"} forces some tool call while leaving the choice to Claude; "auto" is the default and "none" blocks tools. Compatibility with thinking and with each model varies, so check the current API documentation.
What should you return when a tool fails?
For a client tool, return a tool_result tied to the original tool_use_id, set is_error for a real failure and provide concise actionable detail. A valid empty search result is not necessarily a failure. Represent it according to the tool contract.
Do you need to memorise API parameter names for the exam?
Learn the current contract at the depth your guide names. CCAR-F explicitly covers stop reasons, tool result handling, tool-choice modes, strict schemas and error metadata; CCDV-F covers API mechanics and tool implementation. Verify the current guide and platform docs rather than an undated syntax list.
Keep reading
Related posts
Not affiliated with, or endorsed by, Anthropic or Pearson VUE. Details are summarised from publicly published program information and can change. Always confirm against the official exam guide before booking.