Tool Schemas That Do Not Break

Put capabilities in the schema, not the prompt

A model does not learn across sessions. Whatever it worked out painfully in one conversation is gone in the next, so any capability or limit that lives only in a system prompt has to be rediscovered every time.

The schema is different. It arrives with every call, attached to the tool it describes. Ranges, units, enumerated options and what a parameter actually controls belong there, where they cannot drift out of context.

Be explicit about units and ranges

A parameter called duration invites a guess about whether it is seconds or milliseconds, and a model will guess confidently. Name it plainly, state the unit, and give the valid range. The same applies to anything with a real boundary, since a rejected call the model cannot interpret becomes a retry loop.

Frequently Asked Questions

Should capabilities go in the prompt or the tool schema?

The schema. It travels with every call, whereas a system prompt is easy to drop from context and a model cannot carry lessons between sessions.

What do models most often get wrong in tool calls?

Units and ranges. A parameter that does not state whether it is seconds or milliseconds will be guessed at.