Describe your tools well
With a chat model, you write a prompt. With Siliqun Rotor, you describe your tools instead. The engine finds each tool's words in the user's request, so the description is what you tune.
What the engine does with a description
For each request, the engine:
- finds each tool's declared words in the request;
- picks the tool with clearly the most matches (a tie stays a tie, and is returned as unresolved);
- fills in only the argument values it actually finds in the request.
A required value it cannot find becomes ask. If no tool's words appear, the answer is refused. Every answer shows which words matched, in evidence.
Rules that work
1. Write one sentence in your users' own words. Write what the tool does the way a user would ask for it.
| Weaker | Better |
|---|
Retrieves PTO accrual data | Shows how many days of leave an employee has left, by type |
Payroll endpoint | Shows the employee's own payroll: salary, payslips, deductions and payment dates |
2. Use enum for any closed set of values. The engine fills in a value only when it finds it in the request. An enum tells it which words count.
"leave_type": {"type": "string", "enum": ["vacation", "sick", "parental", "unpaid"]}
3. Mark a value required only if the tool truly needs it. A missing required value becomes ask: the engine never invents a date, an amount or an ID. That is the safety you want for an action like booking leave.
4. Keep tools clearly apart. If two descriptions share most of their words, a request that matches both returns unresolved. Give each tool the words that set it apart: balance versus apply, or own versus team.
5. Say when a tool changes data. Describe it as a change ("requests leave", "cancels a request"). Your application then shows a confirmation before it runs the tool.
When a request is refused that should have matched
Read the answer's evidence, and the closest tool if one is named. Then add the user's wording to that tool's description. Don't add a special case in your code.
Values work differently. The engine fills a value only from words it finds in the request. If users say annual leave and your enum says vacation, the engine asks which type instead of guessing. Either accept that question, or name your enum values the way your users say them. The leave assistant example shows real refusals and what to do with each.
Check your descriptions
- Try a dozen real requests in the Studio's Test page.
- Include a few that should be refused.
- Change one description at a time, and read the evidence after each change.