Tool Implementation

Tool Implementation is 4.4% of CCDV-F, the heaviest of the three Tools and MCPs sub-skills, and worth roughly two questions. The parent domain page covers the contract: how a definition is read, how the call and result cycle works, how failures come back. This page is about the design decisions underneath that contract, which is where most real tools go wrong.

The reframing that helps is to stop treating a tool as an exposed function and start treating it as an interface for an unusual kind of caller. That caller reads a short description, cannot see your source, fills in arguments from natural language, receives whatever you return into a window it pays for on every subsequent turn, and may call the same thing twice because it was not sure the first attempt landed. Almost every implementation guideline follows from one of those five properties.

The biggest single lever is what you return. A wrapper forwarding an upstream response verbatim is the default implementation and usually the wrong one: it fills the window with fields nobody will read, buries the two values that mattered, and makes every later turn more expensive. Working out what the model needs in order to take its next step, and returning exactly that, is the job.

What the exam tests here

• •Choosing tool granularity, including when a mode parameter should become separate tools
• •Designing a result payload for a caller that pays for it on every following turn
• •Parameters the model can fill without first computing something
• •Handling repeated or concurrent invocation of a side-effecting tool safely
• •Forcing, permitting or preventing tool use for a particular request
• •Evaluating a tool by whether it gets selected and filled correctly, not only by whether it runs

Granularity: one tool per decision the model makes

Two failure shapes bracket the right answer. A single tool with a mode argument pushes the selection problem inside the schema, where one description has to cover several behaviours with no per-branch guidance: a manage_records tool taking create, update, delete or search is four tools in a trench coat. At the other extreme, twelve near-identical retrieval tools differing by one filter force a choice the model cannot make well.

Split when the branches have genuinely different purposes, arguments or risk profiles, since separate tools give you separate descriptions, separate schemas and separate permission decisions. Merge when the difference is a parameter a caller would naturally supply. The question is whether the model needs different guidance for the two cases.

Design the return value for the window it will live in

A result is not a response to a client that renders it once. It is context persisting for the remainder of the conversation and resent on every following turn. A tool returning a whole file when a signature was wanted, or two hundred search hits when three were needed, imposes that cost repeatedly.

Return the smallest thing that lets the model take its next step: a short summary, the specific fields bearing on the decision, and identifiers it can use to request more. Paginate rather than truncate blindly, and state in the result that more exists, because a silently shortened list gets treated as complete. Prose with embedded identifiers is often easier to act on than a deeply nested object, and it costs fewer tokens than the same facts wrapped in structure.

Parameters the model can fill without doing arithmetic

Every argument the model has to derive is an opportunity to derive it wrong. Relative dates computed against today, offsets into a list, paths assembled from a working directory it is inferring, values requiring a lookup before the call: all fail occasionally, and the failure is silent, because a well-formed call carrying a wrong value produces a plausible result.

Design them out. Accept an absolute date and a duration rather than an implied window, take a full path rather than a fragment to resolve, name the enumerated value rather than its numeric code. Where a fixed set exists, express it as an enumeration so a wrong value becomes impossible rather than unlikely, and where a default is sensible, apply it in the implementation instead of demanding one.

Repeat calls, and effects that outlive them

A model may invoke the same tool twice: because a result was ambiguous, because a timeout returned nothing and it tried again, or because a parallel batch contained a duplicate. For anything read-only that is merely wasteful. For anything that creates, charges, sends or deletes, it is a defect that appears in production and never in testing.

Make the operation safe to repeat. Accept a caller-supplied key so a second identical request returns the first outcome instead of performing the action again, or check for an existing matching record before creating one. Where an action genuinely cannot be made repeatable, put it behind a confirmation step so repetition needs a human. And return something definitive on timeout, since an ambiguous outcome is what provokes the retry.

Where candidates go wrong

Common questions