8.1 — Tool Implementation

CCDV-F Domain 8 · Task 8.1

What You Need to Know

A tool is an action Claude can ask for. A tool you define has three parts: name, description, input_schema. When the model decides whether to call a tool, it reads only those three surfaces. If it chose badly, the information it needed was missing from one of them.

What a Description Has to Say

Anthropic ranks the description above the schema and the model. Checklist:

• what the tool does
• when it should be used, and when it should not
• what each parameter means and how it affects behaviour
• important caveats, including what information the tool does not return

Floor: at least three to four sentences. Disambiguation is a sentence in both directions — each description names the sibling tool and states the boundary.

The Schema Is the Other Half of the Contract

Closed sets → enum. Mandatory fields → required. Units and formats → per-property description. input_examples attaches validated example inputs. strict: true guarantees schema-conformant inputs.

What the Tool Returns When It Fails

Interface design, not exception handling. Pattern: tool_result with is_error: true and a body written for a reader who must decide what to do next — what went wrong and what to try next. Empty lists and last-known-good values produce fabrication. Server tools: API handles their errors; you do not set is_error.

Where the Code Runs

Type	Who executes	Reach
Client tool	Your process	Your network, your credentials
Server tool	Anthropic	Platform environment only

Anthropic-provided ≠ Anthropic-executed. Some Anthropic-schema tools are client tools.

Dispatch and Approval

Harness resolves name → handler, validates, applies policy, executes under timeout, logs, formats result. Independent read-only calls can run in parallel; side-effecting calls one at a time. Approval classification is a design decision made when the tool set is designed.