Claude tool use and structured output, as the exams test them

Claude tool use and structured output are both contracts, and neither is an execution. Claude names a tool and its arguments and then stops — your code is the only thing that runs anything, and the turn continues because a declared stop state says it must. Structured output is that same contract aimed at shape instead of action. Neither says a word about whether the values are right.

Who actually runs the tool

The single most useful thing to hold onto: the model proposes, it never executes. What comes back is a request naming a tool and the arguments to call it with, and nothing has happened yet. That is why this whole subject is a handoff rather than a feature, and why the first question about any tool is whose machine actually runs it.

That question has more than one answer. Some tools you define and run. For some, the schema is published for you but your code still executes them. Some run entirely on the provider's infrastructure and need no result back at all — building one anyway breaks the next request. Tool use is also the mechanism agents are built out of, but the shape of a system around these calls is a separate question from the contract itself.

Why the description does more work than the schema

Both exam guides land on this independently, and it is the finding most likely to change how you build a tool: the description — not the name, not the type system — is what decides whether the right tool fires. It is the part a developer skims and the part the model actually reads at decision time.

Three things follow. When two tools could plausibly apply, the fix is nearly always in the prose that distinguishes them rather than in the types. One tool covering several unrelated operations is worse than several clean ones, because nothing in the description can then say when to use it. And marking every argument required "to be safe" is not safe — it forces the model to supply values it has no basis for, which is how a well-typed, entirely invented argument arrives.

Forcing a call, and when not to

Tool choice is a posture, not a paragraph of prompt. You can let the model decide, force it to use some tool, force one named tool, or block tool use entirely. Letting it decide is the sensible default whenever tools are supplied.

The exam point is not the four names, it is when forcing is defensible. Force when the task requires a call — an action that must happen, data that must be fetched — not to make behaviour feel more predictable. Forcing an unnecessary call produces one, with arguments invented to fill it.

Three levels of guarantee

There are three ways to get shaped output back, and only two of them are guarantees.

Reach past prompting whenever a downstream system cannot tolerate a malformed field. Which of the two real mechanisms you pick depends on whether the output is naturally framed as the model calling a function, or as it simply returning an object.

Where Claude tool use and structured output fails first

Almost never inside the model, and almost never inside the tool. It fails in the handoff — because the message passing between them is the only surface the two sides share, and each side can pass its own tests while the connection between them is broken. That is what makes these failures hard: nothing crashes on the side you are looking at.

Two of those are worth saying out loud. A single turn can legitimately carry several independent requests, so code assuming exactly one drops the rest without erroring — and calls whose input depends on another call's output must be sequenced rather than batched, however tempting it is to save a turn.

And the authoritative signal is a declared state, not an impression. Claude often narrates what it is about to do alongside the actual request; that narration is ordinary text, not a machine-readable signal. Deciding whether a turn is finished by how the prose reads, rather than by the state the response declares, is one of the most reliably-scored wrong answers in this material. Both Claude Certified Developer – Foundations and Claude Certified Architect – Foundations examine it.

Key takeaways

• Claude proposes; your code executes. Nothing has happened when a call comes back — which is why the first question is whose machine runs it.
• The description decides which tool fires, not the name and not the types. It is the part everyone skims and the model reads.
• Marking every argument required is not safe. It forces values the model has no basis for, and they arrive well-typed and invented.
• A schema guarantees the container, never the contents. Shape-valid is a different claim from correct.
• Return failures explicitly. An empty result reads as valid data, and the model will reason confidently on top of nothing.