Loading ToolBench

Reading the current corpus…

task-mcp MCP server · F · ToolBench

← Browse

task-mcp

github.com/prmichaelsen/task-mcp

MCP server for autonomous task execution with ACP-style task management

<=2025-11-25STDIO13 tools

34/100

Definition Quality43

Protocol Readiness32

Supportability21

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Sampling

Deprecated protocol patterns detected

Summary

Task-mcp has 13 tools with consistent naming (task_verb_entity pattern) and basic schemas. However, most tool descriptions are minimal (10-50 chars), parameter descriptions lack detail, and output schemas are undocumented. No tool annotations (readOnlyHint/destructiveHint). Error handling is generic. The server follows a CRUD structure but lacks LLM-optimized guidance on when/why to use each tool. Descriptions do not explain dependencies (e.g., create_milestone requires task_id first) or recovery paths.

Tools (13)

task_add_messagewritesource verified57/100

Add a message to the task conversation thread

task_create_milestonewritesource verified67/100

Create a new milestone in a task. NOTE: Milestones correspond to ACP Milestones and should follow this structure: Use the 'description' parameter to provide the full milestone content following this structure.

task_create_taskwritesource verified72/100

Create a new task with title and description. NOTE: Tasks in this system correspond to ACP Projects. The task's progress structure follows the ACP progress.yaml format with: - Milestones (major phases) - Task Items (granular work items within milestones) - Progress tracking (percentages, status, completion dates) After creating a task, use: - task_create_milestone to add milestones - task_create_task_item to add task items to milestones - task_update_progress to track overall completion The progress structure matches agent/progress.yaml format but stored as Firestore objects.

task_create_task_itemwritesource verified67/100

Create a new task item within a milestone. NOTE: Task items correspond to ACP Tasks and should follow this structure: Use the 'description' parameter to provide the full task content following this structure.

task_delete_taskdestructive37/100

Delete a task

task_get_milestoneread only

Issues (5)

HIGHtool-description ↗

Minimal tool descriptions (10-50 chars) lack LLM guidance on when/why to use each tool. 'Get list of tasks' and 'Get a single task by ID' do not explain selection criteria, filtering, or pagination. LLMs cannot distinguish between similar tools.

task_get_taskstask_get_tasktask_get_milestonetask_get_task_item

HIGHresponse-shaper ↗

No output schemas documented. Callers cannot know what fields to expect from get_tasks, get_task, or create_task responses. This breaks tool chaining, LLMs cannot extract IDs for downstream calls.

task_create_tasktask_get_taskstask_get_tasktask_create_milestonetask_create_task_itemtask_add_message

HIGHtool-annotations ↗

No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Clients cannot distinguish safe reads from destructive writes. task_delete_task should be marked destructiveHint=true; task_get_* should be marked readOnlyHint=true.

task_delete_task

Recommendations

Expand tool descriptions to 100-200 chars. For each tool, state: WHAT it does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'Get a single task by ID. Use this after create_task to retrieve the task object and extract milestone_ids for downstream calls. Returns task object with id, title, description, milestones array, and progress percentage.'
Document output schemas for all tools. Add a 'Returns' section to each tool description listing field names, types, and meanings. Example: 'Returns: {id: string, title: string, milestones: [{id: string, name: string, tasks: [...]}], progress: number (0-100)}'
Add tool annotations to all tools. Mark task_delete_task with destructiveHint=true. Mark all task_get_* and task_update_progress with readOnlyHint=true (or false for writes). Mark idempotent operations (e.g., create with explicit ID) with idempotentHint=true.
Enhance parameter descriptions with format, length, and constraint details. Example: 'task_id (string, UUID format, required): The unique identifier of the task. Obtain from create_task or get_tasks response.' For enums like role in task_add_message, state: 'role (enum: user|assistant|system): The message sender role. Use "assistant" for LLM responses, "user" for human input.'
Add dependency hints to descriptions. Example: task_create_milestone should state: 'Requires: task_id from create_task or get_tasks. After creating, use task_create_task_item to add work items to this milestone.' This guides multi-step planning.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Sampling (deprecated) - integrate directly with the LLM provider API

Score history

Overall score trend

First recorded score · v2 rubric

34/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	34	<=2025-11-25	v2