Loading ToolBench
Shrimp Task Manager is a task tool built for AI Agents, emphasizing chain-of-thought, reflection, and style consistency. It converts natural language into structured dev tasks with dependency tracking and iterative refinement, enabling agent-like developer behavior in reasoning AI systems
This server demonstrates significant definition quality issues across nearly all dimensions. Descriptions are loaded externally from markdown files (toolsDescription/*.md) that are not visible in the provided source code, making them impossible to evaluate. Input schemas are minimal and incomplete, most tools accept only a single parameter (taskId, query, topic, etc.) with no type constraints, enum values, or validation hints. No output schemas are documented. Error handling and recovery guidance are absent from all tool definitions. The 15-tool set shows poor composition: many tools overlap conceptually (plan_task, analyze_task, reflect_task, process_thought all appear to handle reasoning/decomposition), and there's no clear distinction between what makes each tool necessary. Parameter naming is generic ('taskId', 'topic', 'query') without type suffixes. No security considerations are visible (e.g., permission gates on destructive tools like delete_task and clear_all_tasks). The architecture suggests a monolithic task system rather than a composable set of focused tools.
Analyze a task in detail (loaded from toolsDescription/analyzeTask.md)
Clear all tasks (loaded from toolsDescription/clearAllTasks.md)
Delete a task (loaded from toolsDescription/deleteTask.md)
Execute a task (loaded from toolsDescription/executeTask.md)
Get detailed information about a task (loaded from toolsDescription/getTaskDetail.md)
Initialize project rules (loaded from toolsDescription/initProjectRules.md)
List all tasks (loaded from toolsDescription/listTasks.md)
Tool descriptions not visible in source code, loaded from external markdown files (toolsDescription/*.md) that were not provided for evaluation. Cannot assess description quality, LLM-readiness, or why/when to use each tool.
Input schemas are minimal and lack type constraints. Most tools accept a single string parameter (taskId, query, topic, thought, rules) with no enum values, format specifications, or validation constraints. Schemas do not guide LLM input generation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 18 | - | v1 |
Plan a task based on user input (loaded from toolsDescription/planTask.md)
Process chain-of-thought reasoning (loaded from toolsDescription/processThought.md)
Query task information (loaded from toolsDescription/queryTask.md)
Reflect on a task (loaded from toolsDescription/reflectTask.md)
Enter research mode for exploring tasks (loaded from toolsDescription/researchMode.md)
Split tasks into subtasks (loaded from toolsDescription/splitTasks.md)
Update task content (loaded from toolsDescription/updateTask.md)
Verify a task (loaded from toolsDescription/verifyTask.md)
No output schemas documented. LLMs cannot infer what fields will be returned, what types they are, or what downstream tools can accept. This breaks tool chaining and forces agents to guess.
Semantic overlap and poor composition. plan_task, analyze_task, reflect_task, and process_thought all appear to handle task reasoning or decomposition, no clear distinction of responsibilities. This violates the single-responsibility principle and wastes LLM reasoning on disambiguation.
No permission gates or security declarations on destructive tools. delete_task and clear_all_tasks (marked DESTRUCTIVE risk) do not appear to require confirmation, permission checks, or dry-run support. This risks accidental data loss.
No error handling or recovery guidance visible. Tool definitions do not explain what errors can occur, how to handle them, or what the LLM should do next (retry, ask user, call a different tool).
Tool name ambiguity: 'query_task' is vague, does it search tasks, run a pre-defined query, or retrieve by criteria? Name does not convey intent. Consider 'search_tasks' or 'filter_tasks' for clarity.
Parameter naming lacks type context. Many parameters are bare 'taskId', 'query', 'topic' without suffix hints. No distinction between taskId (system UUID) and task name (user-facing), this forces LLMs to guess which to pass.
list_tasks accepts a 'status' parameter without defining valid enum values. What statuses are allowed? 'pending', 'active', 'done'? 'todo', 'in_progress', 'completed'? LLM must guess or hallucinate.
clear_all_tasks requires a 'confirm' boolean but no guidance on what happens. Does it delete permanently? Is there a recovery window? What does the response contain? Destructive operations need clear semantics.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in source. This metadata helps clients (IDEs, hosted LLMs) apply safety guardrails automatically.