Your tool catalog is part of the input
When you give an AI assistant tools, you usually send more than the user's question. You also send a catalog describing what each tool does and which arguments it accepts. That catalog takes up tokens, the small pieces of text models process and providers bill for.
A tool description might explain how to search documents, create a ticket, or look up an order. If it reads like a help article, you may be paying for sentences the model does not need. The goal is simple: keep the instructions that guide decisions, and remove the rest.
Start with one wordy tool description
Choose a tool with an obvious purpose. Read its description and ask what the assistant actually needs to know before calling it. Usually, that means the action it performs, when to use it, and any important limits.
Before: “This tool allows you to search through the company's internal knowledge base to find helpful documents and information that may be relevant to answering the user's question. You should use this tool whenever you need to locate internal documentation. The search query should contain relevant search terms.”
After: “Search internal documentation. Use for questions requiring company-specific information. Provide a keyword query.”
The shorter version keeps the purpose, selection rule, and query guidance. It removes introductory wording and repeated explanations. This is a useful first edit because it changes the wording without changing the tool's intended behavior.
Keep the rules that prevent wrong calls
Shorter is not automatically better. A description that says only “Search” may leave the assistant guessing whether it searches the web, internal documents, or customer records. Preserve details that distinguish one tool from another.
- Scope: State what data the tool can access, such as public articles or the current customer's orders.
- Selection rules: Explain when to use the tool, especially when another tool has a similar purpose.
- Argument requirements: Keep units, accepted formats, and meaningful restrictions.
- Consequences: Clearly identify tools that send messages, change records, or spend money.
- Confirmation rules: Preserve required approval steps, and enforce critical safeguards in your application as well.
For example, “Cancel an order” is incomplete if cancellation is allowed only before shipment. Keep that restriction even if it adds words. A small token saving is not worth an incorrect action.
Remove repetition across the tool schema
Descriptions are only one part of a tool definition. Names, argument descriptions, types, and required fields also help explain the interface. Read them together before deciding what to cut.
If an argument is named customer_email and its description already specifies an email address, the main tool description rarely needs to repeat that explanation. Likewise, avoid restating every required field in prose when the schema already marks those fields as required.
Keep examples only when they resolve real ambiguity. A date format example can be useful; several nearly identical examples usually add little. Do not remove structural schema information just to make the definition shorter.
Check token savings alongside tool accuracy
Save the original definition, then test the edited version with the same model and settings. Include ordinary requests, ambiguous requests, and requests where the assistant should not call a tool.
- Does the assistant choose the right tool?
- Does it provide valid, complete arguments?
- Does it respect scope and confirmation requirements?
- Does reported input-token usage decrease?
Use provider usage data rather than guessing from character counts. Tokenization varies, and some systems apply prompt caching or handle tool definitions differently. Shorter definitions can reduce input tokens when included in a request, but the billing effect depends on the provider and caching behavior. Check actual usage and charges.
Make description trimming a repeatable habit
Review tool descriptions whenever you add a tool or change its behavior. Keep a small set of test requests so future edits do not quietly weaken tool selection.
If you want to try this through a pay-as-you-go relay, SwiftRelay works with OpenAI-compatible SDKs and bills per token. Sign up for SwiftRelay to use the small gift credit available to new accounts while testing your revised definitions.
Start with one tool, remove repetition, and check the results. The best description is not the shortest possible sentence; it is the smallest explanation that still supports reliable tool use.