Loading ToolBench
MCP server for managing background tasks with full lifecycle control and stdout/stderr monitoring
This server implements 6 background task management tools with explicit schema definitions and descriptions. All tools are registered with inputSchema using Zod and descriptions are present. However, there are significant gaps in definition quality: (1) parameter descriptions are minimal and lack actionable constraints; (2) output schemas are not formally documented, responses are unstructured text wrapped in content[] arrays, not typed objects; (3) error messages are generic and lack recovery guidance; (4) descriptions lack WHEN to use guidance and dependency hints. The server follows basic tool patterns but falls short of LLM-optimized definitions.
Retrieves the stderr of a running background task.
Retrieves the stdout of a running background task.
Lists all currently running background tasks.
Runs a long-running command (like 'npm run dev') in background. When the command is running, you can interact with it using other tools.
Sends data to the stdin of a running background task.
Stops a running background task by its name.
No formal output schema documentation. All tools return unstructured text in a content[] array. LLMs cannot plan downstream operations or extract structured fields. The response type is text blob, not a typed object with fields like {status, pid, stdout, stderr, runningTasks}.
Parameter descriptions are too minimal. 'Unique name of the task' and 'Shell command to run in background' lack actionable constraints. No guidance on format (e.g., 'task name must be alphanumeric, 1-100 chars'), no hints about when to use each tool (e.g., 'Use run-background-task to start a long-running process like a dev server'), no dependency documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Error messages lack recovery guidance. When a task is not found, the response is 'No task found with name "name". Rather than returning a corrective hint like 'Call list-background-tasks to see available tasks', the LLM is left to infer the next step. This wastes tokens and invites wrong tool selection.
Tool descriptions do not state WHEN to use each tool vs. alternatives. 'Runs a long-running command' doesn't explain the difference from shell execution or when an agent should prefer this server. Tool descriptions must answer: What does it do? When should the LLM select this tool instead of a similar tool? What does it return?
send-to-task-stdin lacks error categorization. The error 'Child process stdin is not available' is returned as plain text, not categorized as retryable or fatal. LLMs cannot infer whether to retry, ask the user, or fail the plan.
run-background-task should document constraints on task names. Can duplicate names be started? Are names case-sensitive? What characters are allowed? Without constraints, LLMs may pass invalid values like 'task name with spaces' or non-unique duplicates.
No support for confirmation or dry-run on destructive operations. stop-background-task and send-to-task-stdin modify state irreversibly. There is no confirmation_required hint or dry-run option to prevent agent mistakes.
Missing pagination support. If a process generates very large stdout/stderr, get-task-stdout and get-task-stderr return the entire buffer as a single string, risking context window exhaustion. Should support limit and offset parameters.