Loading ToolBench
A Model Context Protocol server for task orchestration and management.
Server has 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (create_goal, add_tasks, get_tasks, remove_tasks, complete_task_status). Descriptions are present and substantive (100-200 chars), explaining what each tool does and key behaviors. However, parameter descriptions lack actionable constraints (no ranges, patterns, or format guidance). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance or categorization. Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, READ_ONLY, REVERSIBLE). Schemas are well-formed JSON Schema with $ref definitions, but lack examples and validation rules.
Add multiple tasks to a goal. Tasks can be provided in a hierarchical structure. For tasks that are children of *existing* tasks, use the `parentId` field. The operation is transactional: either all tasks in the batch succeed, or the entire operation fails.
Update the completion status of tasks. Task IDs use a dot-notation (e.g., "1", "1.1", "1.1.1"). Responses will return simplified task objects without `createdAt`, `updatedAt`, or `parentId`.
Create a new goal
Get tasks for a goal. Task IDs use a dot-notation (e.g., "1", "1.1", "1.1.1"). When `includeSubtasks` is specified, responses will return hierarchical task objects. Otherwise, simplified task objects without `createdAt`, `updatedAt`, or `parentId` will be returned.
Soft-delete multiple tasks from a goal. Tasks are marked as deleted but remain in the system. Task IDs use a dot-notation (e.g., "1", "1.1", "1.1.1"). Responses will return simplified task objects without `createdAt`, `updatedAt`, or `parentId`. Soft-deleted tasks are excluded by default from `get_tasks` results unless `includeDeletedTasks` is set to true.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Forces agents to guess what data is returned.
Parameter descriptions lack actionable constraints. 'goalId' is described as '(number)' but no range, min/max, or valid values. 'includeSubtasks' enum is declared but description repeats enum values instead of explaining when to use each.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with Risk levels (WRITE, REVERSIBLE, READ_ONLY) in metadata but not exposed via MCP tool annotations. Agents cannot infer safety/idempotency from tool definitions alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Error handling is minimal. No recovery guidance, error categorization, or actionable messages. If a task ID is invalid or a goal does not exist, agents receive no hint on what to do next.
Irreversible operations (remove_tasks, complete_task_status) lack confirmation or dry-run support. Agents can soft-delete or mark tasks complete without a safety gate, risking accidental data loss.