Advanced

Tool use

Give Claude tools and functions to call — and design them so it calls them well.

Knowledge cards
Best practice
Describe Tools Like You'd Brief a New Hire
A tool-design principle for function calling: write each tool's description and parameter docs as if briefing a capable new hire who's never seen your system — what it does, when to use it (and when not), what each argument means, and what happens on failure — rather than a terse one-liner.
L4 · Multi-AI systems
Best practice
Give Claude Fewer, Sharper Tools
A tool-set design principle: expose the smallest set of tools that covers the job, each doing one clear thing, rather than a sprawling menu with overlapping or near-duplicate functions. Tool accuracy is a selection problem before it's a calling problem.
L4 · Multi-AI systems
Best practice
Make Tools Fail in a Way Claude Can Recover From
A design rule for tools Claude calls: when a tool fails, return an error the model can act on — what went wrong, why, and what a valid call would look like — instead of a raw stack trace or a bare status code. The error message is part of the prompt Claude reads next.
L4 · Multi-AI systems
Best practice
Get Structured Output You Can Trust, Not Just JSON-Shaped Text
A practice for getting machine-readable output: define the exact schema you need, ask Claude to produce only that, and then validate the result against the schema in your code — treating the model's output as untrusted input to be checked, not as guaranteed-valid data.
L4 · Multi-AI systems
Claude tool use

Describe tools like you'd brief a new hire

Tool use gives Claude functions it can call — to fetch data, run actions, or reach your systems — and the quality of its calls tracks the quality of your descriptions. Describe each tool the way you would brief a capable new hire: a clear name, what it is for, when to use it, and exactly what inputs it expects. A vague or overlapping set of tools leads to wrong or missed calls; a clean, well-named set lets Claude pick the right one reliably. The interface is the instruction.

Return structured output you can trust

For tool use to be dependable in real software, Claude needs to return output in a shape your code can consume — not prose you have to parse and hope. Specify the structure precisely and ask for exactly that. Combined with clear tool descriptions, this turns Claude into a component you can wire into a system: it calls the right function, with the right inputs, and hands back something predictable. That reliability is what separates a demo from something you can put into production.

Frequently asked
How does tool use work with Claude?

You give Claude functions it can call, each described with a clear name, purpose, and expected inputs. It then chooses and calls the right tool — the quality of its calls depends on how well you describe them.

Why does Claude call the wrong tool?

Usually because the tools are vaguely or overlappingly described. A clean, well-named set with clear purposes and inputs lets it pick reliably.

How do I get reliable structured output from Claude?

Specify the exact shape you want and ask for precisely that, so your code can consume it without parsing prose. Clear tool descriptions plus a defined output shape make tool use production-ready.