Loading ToolBench
Manage long-running dev tasks from VS Code and MCP with shared process supervision, reliable start/stop, and file-backed logs for AI agents.
TaskDev provides 9 well-structured tools with complete JSON Schema definitions and consistent descriptions. All tools have input schemas with typed parameters and descriptions. Tool names follow verb_noun convention (taskdev_list, taskdev_control, taskdev_logs). However, descriptions are brief (avg ~80 chars) and lack actionable context for LLM selection. Error handling guidance is absent, tools do not explain recovery paths or categorize failures. Output schemas are not documented. The confirmation pattern for destructive operations (taskdev_remove, taskdev_add) is good, but lacks dry-run support. No tool annotations (readOnlyHint, destructiveHint) are present in the schema.
Add a safe new task to the selected project taskdev.json. Requires confirm to equal ADD <name>.
Start or stop a taskdev task by name.
List defined taskdev tasks with status and pid. Pass project to disambiguate in multi-project workspaces.
Read the tail of a task log. Defaults to the last ~100 lines (capped at 32 KB) of the most recent run. Raise `bytes` (up to 131072) for more context. To inspect a previous run, call `taskdev_logs_history` first and pass its `file` here. For deeper analysis of huge logs, read the file directly using the `path` returned by `taskdev_logs_history` — this tool intentionally bounds response size.
List previous log files for a task (newest first). Pass file from a result back to taskdev_logs to fetch its contents.
List taskdev projects discovered across all configured workspace folders.
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, forcing them to guess at downstream field names and risk broken tool chains.
Descriptions are too brief (avg 60 - 75 chars) and lack context for LLM selection. E.g., 'Get status for one task, or all tasks when name is omitted' does not explain when to call this vs taskdev_list, or what the response structure is.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., taskdev_control does not explain what happens if a task is already running or if the project is not found.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Remove a task from the selected project taskdev.json. Requires confirm to equal REMOVE <name>.
Stop and restart a task by name.
Get status for one task, or all tasks when name is omitted.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in schemas. LLMs cannot determine which tools are safe to retry or which modify state without reading descriptions.
taskdev_add and taskdev_remove require a confirmation string (e.g., 'ADD <name>') but lack dry-run support. Agents cannot preview the change before committing, increasing risk of mistakes.