Loading ToolBench
MCP server for cron task scheduling (shell commands and AI prompts)
The server defines 12 tools with mostly complete schemas and descriptions. Tool names follow verb_noun conventions and are action-oriented. Most tools have parameter descriptions. However, there are several definition quality gaps: (1) parameter descriptions are generic and lack actionable details about formats, ranges, or constraints; (2) output schemas are not documented in the visible source (responses are inferred but not formally specified); (3) error handling guidance is minimal, tools do not indicate what errors are retryable, user-fixable, or fatal; (4) some tools like add_task, add_ai_task, add_http_task have redundant parameters (the 'type' field is documented but rarely used since the tool name already indicates the type); (5) security considerations for executing arbitrary shell commands and HTTP requests are not documented. The server does show good patterns: descriptions are present for all tools and parameters, schemas include proper types, and most tools are single-responsibility. However, the descriptions are surface-level and do not provide the context LLMs need for confident tool selection and use.
Adds a new AI (LLM) task. Requires 'name' and 'prompt'. Provide 'schedule' for recurring execution or omit it to create an on-demand task triggered via run_task. Set 'enabled' to true to activate immediately.
Adds a new HTTP (webhook) task. Requires 'name' and 'url'. 'method' defaults to POST. 'headers' is a JSON object of string→string. 'body' is the request body. Provide 'schedule' for recurring execution or omit it to create an on-demand task triggered via run_task. The result captures HTTP status (as exit_code), response body preview (as output), and round-trip latency (as duration).
Adds a new shell command task. Requires 'name' and 'command'. Provide 'schedule' for recurring execution or omit it to create an on-demand task triggered via run_task. Set 'enabled' to true to activate immediately.
Disables a task so it stops running and cannot be triggered
Enables a task so it runs on its schedule or can be triggered via run_task
Gets a specific task by ID
Output schemas not documented. While tools have input schemas with types and descriptions, there is no formal documentation of what each tool returns (response fields, types, structure). This forces LLMs to infer output shapes and makes tool chaining unreliable.
Parameter descriptions lack actionable constraints. For example, 'schedule' accepts cron expressions but the description does not document valid formats, error handling for invalid cron strings, or examples of common patterns. 'limit' in get_task_result is described generically but lacks explicit min/max bounds (rubric states max is 100 but LLMs cannot infer this from the description alone).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Gets execution results for a task. Returns the latest result by default, or recent history when limit > 1.
Lists all tasks (scheduled and on-demand)
Run a read-only SQL query against the database. Only SELECT statements are allowed. Results are capped at 1000 rows. The output column can be large — use SUBSTR(output,1,500) or LIMIT to manage response size.
Permanently removes a task by ID
Executes a task by ID, waits for completion, and returns the result. Use this to trigger on-demand tasks (created without a schedule) or to manually run a scheduled task outside its normal schedule.
Updates an existing task. Requires 'id'. Only provided fields are updated; omitted fields remain unchanged.
Error handling and recovery guidance missing. Tools do not indicate what happens on failure (e.g. if cron parsing fails for 'schedule', if HTTP request times out in add_http_task, if SQL query in query_task_result is malformed). No guidance on retryable vs fatal errors, or what the LLM should do next.
Security concerns undocumented for shell_command and http task types. Running arbitrary shell commands (add_task/update_task with type='shell_command') carries injection risks. Making arbitrary HTTP requests (add_http_task) can be used to scan internal networks or exfiltrate data. No mention of sandboxing, command allowlisting, network policies, or audit logging in the tool descriptions.
Redundant 'type' parameter in add_task, add_ai_task, add_http_task. Each tool's name already indicates the type (add_task → shell_command, add_ai_task → AI, add_http_task → http). The 'type' parameter is documented in all three but rarely used, creating confusion about whether it overrides the tool name or should always match. This violates single-responsibility principle.
Missing idempotency guarantees. Tools like run_task, enable_task, and disable_task do not document whether repeated calls with the same input produce the same result or have side effects. Agents retry on ambiguous failures, non-idempotent tools risk duplicate task executions or state inconsistencies.
query_task_result allows arbitrary SELECT queries but lacks input validation guidance. While the description notes 'Only SELECT statements are allowed' and '1000 row cap', there is no mention of SQL injection prevention, query timeout, or what happens if a malicious query is passed. LLMs can be tricked into passing SQL payloads.