Loading ToolBench
MCP server exposing a task management API with authorization, audit logging, and resource templates. Part of the PRISM D1 Velocity AI-DORA metrics platform.
Five tools with explicit schemas and descriptions visible in tool-registry.ts. All tools have action verbs (list_, create_, update_, delete_, search_) and enum-constrained parameters where appropriate. Descriptions are present but brief (avg ~80 chars, below the 194-char baseline). Parameter descriptions are minimal, most lack detail on format, constraints, or when to use. Output schemas are not documented. Error handling guidance is absent. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. Composition is sound: each tool has one responsibility, and naming is clear and unambiguous.
Create a new task. Title is required. Description, status, and tags are optional.
Delete a task by ID.
List all tasks. Optionally filter by status (todo, in-progress, done).
Search tasks by keyword. Matches against title, description, and tags.
Update an existing task by ID. Any combination of title, description, status, and tags can be provided.
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., task_id for chaining). Responses must include structured field definitions.
Tool annotations missing. delete_task is destructive and create_task/update_task are write operations, but no destructiveHint or readOnlyHint tags present. Agents cannot distinguish safe from risky calls.
Parameter descriptions lack actionable detail. 'Filter tasks by status' does not explain when to use this vs. search_tasks. 'Task title (required)' does not specify length limits, character restrictions, or format. Descriptions should be 50-200 chars and include constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | <=2025-11-25 | v2 |
No error handling guidance. If delete_task fails (e.g., task not found), the response should guide the LLM: 'Task not found. Try search_tasks() first.' Currently, error responses are not documented.
No pagination or result limits documented. list_tasks and search_tasks may return unbounded results, risking context window exhaustion. Should accept limit/offset and return total_count.