Tool schemas carrying dead weight
Long descriptions, JSON Schema boilerplate, and enums with a hundred values.
A tool description should tell the model when to reach for the tool. It does not need usage examples, changelog notes, or a restatement of what each parameter type is — the schema already declares the types.
JSON Schema metadata is the common offender. `$schema`, `$id`, `title` and `default` are for validators and documentation generators. The model gains nothing from them and you pay for them on every request.
Enums deserve their own attention. A `country` parameter with all 249 ISO codes inline is over a thousand tokens on every call. Accept a free string and validate on your side, or narrow the list to what your product actually supports.
A good target is one or two sentences per tool and one clause per parameter. If a tool needs three paragraphs to explain, it is usually two tools.
"description": "Use this tool to search. Example: search({query: 'x'}). Note: added in v2.1. The query parameter is a string...""description": "Search the product catalogue. Prefer this over answering from memory."Check your own prompt
The analyser checks this pattern along with the other 25, prices each finding against your request volume, and hands back a rewritten prompt. It runs in your browser — nothing is uploaded.
Run the analyserMore on tools & schemas
- JSON indented for a human readerPretty-printing JSON in a prompt adds 20-30% tokens for whitespace nobody reads.
- A JSON schema written out in EnglishDescribing your output shape in prose costs more than declaring it, and works less well.
- What your tools cost before anyone calls oneTool schemas are re-sent on every request, plus a provider system prompt you never see.