Loading ToolBench
A Go-based Model Context Protocol (MCP) server for storing and managing commonly performed tasks in a git repository. Enables storing, retrieving, and managing frequently used tasks with workflow relationships (prerequisites, required follow-ups, suggested follow-ups).
Server provides 8 tools with complete schemas and descriptions. All tools have clear action-verb naming (list_, get_, add_, update_, delete_) and reasonably detailed descriptions (100-300 chars each). However, several critical issues limit production readiness: (1) Parameter descriptions lack constraints and formats, e.g., 'id' parameters have no format guidance; (2) Output schemas are completely undocumented, no mention of return types, field structures, or pagination; (3) Error handling guidance is absent, no indication of failure modes or recovery paths; (4) No tool annotations despite write/destructive operations; (5) Parameters like 'tags' array accept unbounded input with no validation hints. The design is solid for a task workflow system, but production deployment would require error documentation, output schema specification, and parameter constraint clarification.
Create a new task with its complete workflow. Include what needs to happen before this task (prerequisites), what must happen after (required follow-ups), and what's recommended after (suggested follow-ups). Use this to document repeatable workflows so future work can follow the same process. The system ensures workflows stay consistent by preventing circular dependencies.
Remove a task entirely. This automatically cleans up any references to this task in other tasks' workflows. Use this when a task is no longer relevant or has been superseded by a different workflow. This action cannot be undone.
Get the full content of a specific prompt by name. Use list_prompts to discover available prompts first.
Get the complete workflow for a specific task by its ID. Returns the full task description plus related tasks: what must be done first (prerequisites), what must follow (required), and what's recommended (suggested). Use this before starting any task to understand the complete workflow, not just the immediate action. This helps you avoid missing critical steps.
Get all available prompts that can be used with this MCP server. Returns prompt names with their descriptions. Prompts are loaded from the prompts/ directory and can be customized per deployment.
Output schemas completely undocumented. Tools return data structures but no documentation specifies return types, field names, data types, or nesting. LLMs cannot reliably parse responses or chain tool calls without explicit schemas.
Parameters lack constraint documentation. 'tags' array has no max length; 'id' and 'name' have no length/format guidance; array parameters (prerequisiteIDs, downstreamRequiredIDs, downstreamSuggestedIDs) accept unbounded input. LLMs cannot validate inputs or understand valid ranges.
No error handling guidance. Tools do not document failure modes (e.g., what happens if a task ID doesn't exist, if circular dependencies are detected, if tags are invalid). LLMs receive bare errors with no recovery path.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Get all unique tags used across all tasks. Returns each tag with the count of tasks that use it. Use this to discover available tags for filtering and categorization.
Browse available tasks, optionally filtered by tags (e.g., 'backend', 'database', 'deployment'). Returns task summaries with ID, name, and a brief description. Use this to discover relevant workflows when starting work in a new area or looking for standard procedures. If you provide multiple tags, you'll get tasks that match any of them.
Modify an existing task's description or workflow relationships. Use this when a process changes and you need to update the documented workflow - for example, adding a new required step, removing an outdated prerequisite, or refining the task description. The task ID must already exist.
Destructive operation (delete_task) lacks confirmation or dry-run option. No annotation indicating this is irreversible. Agents may accidentally delete tasks without preventive safeguards.
Missing tool annotations. write operations (add_task, update_task) and destructive operation (delete_task) lack readOnlyHint/destructiveHint/idempotentHint annotations. Protocol spec 2026-07-28 expects these for agent safety and decision-making.
No pagination guidance. list_tasks and list_tags accept optional 'tags' filter but do not specify limit/offset/cursor parameters or total count. Large result sets could blow context windows.
Circular dependency detection mentioned in add_task description but not formalized. No clear error message specified for when circular dependencies are detected, preventing LLMs from understanding and handling this failure mode.