Is a model tool just a normal function?

No. The underlying implementation may be a normal function, endpoint, query, or workflow, but the model only sees the advertised contract. The name, description, argument schema, and return description are what it reasons over. If those are ambiguous, even correct backend code can be unusable to the model.

What should a good tool description include?

Include the job the tool performs, when to use it, when not to use it, required inputs, important constraints, side effects, and the shape of the result. If it is read-only, say so. If it returns raw data rather than a finished answer, say that too, so the model knows what work remains.

Why not rely on the function name?

Function names are too small to carry decision rules. A name like search_invoices is useful, but it does not say whether search supports invoice identifiers, customers, date ranges, partial text, or only exact matches. The model may fill in those gaps incorrectly unless the description and schema remove the guesswork.

Designing a tool the model can use

Designing a tool the model can use means exposing a code capability as a clear natural-language contract: what it does, when to call it, what arguments it accepts, and what it returns. The description, name, and schema guide the model’s decision, so they are part of the runtime interface.

The problem is that a language model cannot inspect your implementation or infer all your application conventions. It sees a menu of advertised capabilities and must decide whether any of them are a better path than answering directly. If tools are named vaguely, overlap heavily, or omit limits, the model guesses. That produces unnecessary calls, wrong calls, missing arguments, or arguments shaped in ways your code cannot validate.

A usable tool is described like an interface for a literal developer who only has the docs. Give it a specific name, a purpose statement, the situations where it should be used, and the situations where it should not. The input schema should use field names that match the domain and state constraints plainly. The output contract should say whether the tool returns raw records, a computed result, a status, or enough information for the model to compose an answer.

The trade-off is that precision takes design work and can make tool surfaces less generic. A broad tool such as a generic lookup is easy for the backend to expose, but hard for the model to choose safely. Narrower tools are often easier for the model to use, but can multiply maintenance and create overlaps. The honest answer is context-dependent: optimise for unambiguous selection, valid arguments, and recoverable failure, not for the fewest functions.

Engineers meet this in function calling, agent frameworks, MCP servers, and structured-output integrations. The tool description lives beside the callable code, but it should be reviewed like API documentation and tested like behaviour. When an agent calls the wrong tool, passes malformed input, or skips a tool it needed, the bug is often not in the model or executor. It is in the contract the model was given.

Go deeper

Agents & MCPDesigning a tool the model can useWrite a tool description precise enough that the model picks it for the right reason.Open the lesson

Common questions

Is a model tool just a normal function?: No. The underlying implementation may be a normal function, endpoint, query, or workflow, but the model only sees the advertised contract. The name, description, argument schema, and return description are what it reasons over. If those are ambiguous, even correct backend code can be unusable to the model.
What should a good tool description include?: Include the job the tool performs, when to use it, when not to use it, required inputs, important constraints, side effects, and the shape of the result. If it is read-only, say so. If it returns raw data rather than a finished answer, say that too, so the model knows what work remains.
Why not rely on the function name?: Function names are too small to carry decision rules. A name like search_invoices is useful, but it does not say whether search supports invoice identifiers, customers, date ranges, partial text, or only exact matches. The model may fill in those gaps incorrectly unless the description and schema remove the guesswork.

Every term