Loading ToolBench
A Rust-based AI chat server with tool integration, scheduling, and external command execution capabilities. Supports OpenAI API interactions, built-in tools (goal management, task scheduling), external tools, and features like ASR/TTS, code completion, and Discord bot integration.
The server defines 2 tools with mixed quality. Both tools have reasonable descriptions and properly typed schemas, but there are significant gaps in parameter documentation, error handling guidance, and composition patterns. The schedule_task tool is particularly complex with nested conditional logic that could benefit from clearer error recovery documentation. Neither tool follows the chat-data-model principle of accepting natural identifiers alongside system IDs.
Manages scheduled tasks (cron-like jobs). Use this tool to create, delete, or list periodic tasks that will automatically call another tool at the specified time or interval. **Important:** When creating a task (action='create'), you MUST specify: - `name`: a unique task name. - `schedule` with `job_type` set to either 'interval' (runs every N seconds) or 'daily' (runs at a fixed time each day). - For 'interval': provide `secs` (e.g., 60 for 1 minute, 300 for 5 minutes, 3600 for 1 hour). - For 'daily': provide `hour` (0-23) and optionally `minute` (0-59, default 0). - `tool_name`: the exact name of the tool to invoke when the task fires. This tool must already exist in the system. - `tool_args` (optional): a JSON object with arguments to pass to that tool. **Example 1:** User says 'Save a number to number.txt every minute' → You should set action='create', name='write_number_every_min', schedule={job_type='interval', secs=60}, tool_name='write_file', tool_args={"filename":"number.txt", "content": "123"} **Example 2:** User says 'Run check.py every 5 minutes' → action='create', name='run_check', schedule={job_type='interval', secs=300}, tool_name='run_script', tool_args={"script":"check.py", "args": "null"} **Example 3:** User says 'Daily summary of Hacker News at 6:00 AM' → action='create', name='hacker_news_summary', schedule={job_type='daily', hour=6, minute=0}, tool_name='hacker_news', tool_args={"save_html": true} **For deletion:** action='delete', job_id='<the task's ID>' **For listing:** action='list'
Updates the current goal's status to either completed or blocked. Call this tool only when the conditions described in the goal context are fully met. Do not call it preemptively or for intermediate progress updates.
update_goal_status: Description is clear but lacks context about when NOT to call it. The instruction 'Do not call it preemptively' is guidance that should be paired with explicit error handling (e.g., 'If conditions are not fully met, return an error describing which conditions are unmet'). Currently, there is no documented error response schema.
schedule_task: Extremely verbose description (1200+ chars) buries critical details and includes example values (e.g., 'write_number_every_min', 'write_file', '123') that LLMs tend to reuse literally. The description violates the 10 - 1024 character guideline (p90=392). Critical conditional logic ('job_type=interval requires secs; job_type=daily requires hour') is scattered across the description rather than formally expressed in the schema's dependentSchemas or documented in parameter descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
schedule_task: Parameter 'schedule' has a nested object structure with job_type-dependent required fields, but the schema does not use 'dependentSchemas' or 'dependentRequired' to formally encode these dependencies. The JSON Schema shows 'required: [job_type]' but does not indicate that 'secs' is required when job_type='interval' or 'hour' is required when job_type='daily'. LLMs cannot reliably infer conditional constraints from text descriptions alone.
schedule_task: No documented error responses. What happens if the user calls action='delete' with a non-existent job_id? What if tool_name does not exist in the system? The tool description promises these operations but provides no error recovery guidance per pattern:recovery-guide.
Both tools lack idempotency documentation. update_goal_status does not state whether calling it twice with the same status is safe or will error. schedule_task does not document whether creating a task with a duplicate name will fail, succeed, or update the existing task. Non-idempotent operations risk duplicate side effects when agents retry.
Output schemas are not documented. The tools have input schemas but no documented return types. What does update_goal_status return? What does schedule_task return for action='list'? Agents need to know the structure of responses to plan downstream calls and extract the right data per pattern:tool.
schedule_task's 'tool_name' parameter requires knowledge of all available tools in the system, but there is no list or discovery mechanism documented. An agent cannot know what values are valid for tool_name without prior knowledge or a discovery tool (e.g., list_available_tools). This forces manual discovery or trial-and-error.