What a Tool's Description Field Is Actually For
A tool definition sent to the model has three parts: a name, a
description, and a JSON-schema parameters object. The model
reads all three at inference time before deciding whether to call
the tool and, if so, with what arguments — it never sees your
source code or your internal docs.
What is the primary role the description field plays in that
process?
The correct answer is "The primary signal the model uses to select and disambiguate between tools."
The model has no access to your codebase or internal
documentation beyond what's sent in the request. The name,
description, and parameter schema are the entire API surface it
can read to decide which tool fits the current request and how to
fill its arguments — the same way a developer skimming an API
reference picks a function. A vague or missing description
under-specifies both when to use a tool and when not to, which
directly causes wrong-tool selection, independent of the model's
underlying capability.
The other options describe things the description has no bearing on. It isn't documentation with zero runtime effect — the model conditions on that exact text at inference time. It has nothing to do with how a result gets formatted after a call already happened; that's a function of the tool's return value, not its description. And it isn't logging-only metadata skipped during inference — it's part of every request and is exactly what the model reads to choose.
Share this question