What it is

A tool in Claude Code is not just a function — it is a typed contract. The Tool type (claude-code/src/Tool.ts:362) bundles a human name, an async call implementation, a description, and — the part this page is about — a readonly inputSchema (claude-code/src/Tool.ts:394): a Zod schema declaring exactly which arguments the tool requires and of what type. Before that call body is ever entered, the harness checks the model's proposed arguments against this schema at a single chokepoint. A tool-use whose required field is missing — arriving as undefined — is rejected at that boundary, and the tool body never runs. This page reads that validate-before-run boundary: the menu's recipe card (inputSchema) and the iron rule that the ticket is matched against it before the kitchen moves.

How it works

When the model emits a tool_use, the harness routes it through checkPermissionsAndCallTool (claude-code/src/services/tools/toolExecution.ts:599). Its very first act, before anything else, is to parse the raw input against the tool's schema: const parsedInput = tool.inputSchema.safeParse(input) (claude-code/src/services/tools/toolExecution.ts:615) — the source even annotates why, noting that "the model is not great at generating valid input." If the parse fails (!parsedInput.success), the harness does not call the tool; it formats the Zod error and hands a tool_result back to the model carrying <tool_use_error>InputValidationError: …</tool_use_error> (claude-code/src/services/tools/toolExecution.ts:670). Only on success does control proceed to the tool's own validateInput (claude-code/src/Tool.ts:489, invoked at toolExecution.ts:683), then to checkPermissions — which by contract "is only called after validateInput() passes" (claude-code/src/Tool.ts:500) — and finally to const result = await tool.call(...) (claude-code/src/services/tools/toolExecution.ts:1207). A missing required field therefore cannot reach tool.call; it is stopped at step one with a precise, model-readable error naming exactly which field failed.

Why it matters

This boundary is what makes a tool safe to wire to real side effects. tool.call runs file edits, shell commands, network requests; letting an undefined required argument flow into it would mean the failure surfaces deep inside the tool body — a crash far from its cause — or, worse, a silently malformed operation that "succeeds" on garbage. By parsing against inputSchema first (claude-code/src/services/tools/toolExecution.ts:615) and converting any mismatch into an InputValidationError returned to the model (claude-code/src/services/tools/toolExecution.ts:670), the harness turns "an absent value propagating silently until it detonates somewhere downstream" into "one loud, located rejection at the door" — and because the error names the offending field, the model can repair the call and retry. The layered ordering — schema parse → validateInput → checkPermissions → call (claude-code/src/Tool.ts:489, claude-code/src/Tool.ts:500, claude-code/src/services/tools/toolExecution.ts:1207) — means each guard runs only once the cheaper, earlier guard has already passed.

Read the source

• The Tool contract — name, inputSchema, validateInput, call: claude-code/src/Tool.ts:362, claude-code/src/Tool.ts:394, claude-code/src/Tool.ts:489.
• The validate-before-run chokepoint — inputSchema.safeParse and the InputValidationError early return: claude-code/src/services/tools/toolExecution.ts:615, claude-code/src/services/tools/toolExecution.ts:670.
• The ordering guarantee — checkPermissions only after validateInput, then tool.call: claude-code/src/Tool.ts:500, claude-code/src/services/tools/toolExecution.ts:1207.