Loading ToolBench
MCP server for managing sub-agents that can execute asynchronous sub-tasks and handle bi-directional communication between parent and child agents
This server presents a moderate-quality tool suite for managing subagents. Tool naming is generally clear and action-oriented (run_subagent_*, check_*, update_*, ask_*, reply_*), following verb_noun convention. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Most tools lack detailed descriptions of their return values and error conditions, which LLMs need for proper tool chaining and failure recovery. Parameter descriptions are present but sparse, many lack constraints, ranges, or format guidance. The tool composition is reasonable (single responsibility per tool), but the definitions would not meet production code review standards for an A-grade MCP server.
Enables the subagent to ask a question to the parent agent.
Check the status of a specific message and retrieve the reply if available. This will acknowledge the message if it has been replied to.
Check the status of a subagent run. Since sub-agents can take a while it is recommneded to wait at least 30 or 60 seconds (`sleep 30`) in between polling intervals.
Get the logs of a subagent run. This can be VERY long, so only use this tool if instructed. Requires only the runId.
Enables the parent to reply to a specific question from a subagent.
Delegates the given task to a claude subagent as an asynchronous sub-task. This creates a new agent instance that will handle the provided input independently and report back its results. The task can be short or long-running. Use check_subagent_status with the returned runId to monitor progress, as completion may take some time. Synonyms: Run subtask, run sub-agent, delegate task, delegate sub-task. Run a query through the Claude CLI
No documented output schemas for any tool. LLMs cannot plan downstream tool chaining or extract the correct fields from responses without knowing the structure of returned data.
Parameter descriptions lack format, range, or constraint guidance. For example, 'cwd' is described only as 'Working directory path' but does not specify whether relative paths are accepted, if ~ expansion is supported, or what happens if the directory doesn't exist.
Tool descriptions lack error recovery guidance. For example, check_subagent_status mentions waiting 30-60 seconds but does not explain what status values mean, when to retry, or what to do if a runId is invalid.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Delegates the given task to a q subagent as an asynchronous sub-task. This creates a new agent instance that will handle the provided input independently and report back its results. The task can be short or long-running. Use check_subagent_status with the returned runId to monitor progress, as completion may take some time. Synonyms: Run subtask, run sub-agent, delegate task, delegate sub-task. Run a query through the Amazon Q CLI
Update the status and summary of a subagent run. This tool is meant to be used from sub-agents, not the main agent. Requires runId and status.
Ambiguous parameter names for run_subagent_* tools. The 'input' parameter is generic, does it accept free-form text, a JSON payload, a file path, or structured commands? This forces LLMs to guess.
update_subagent_status includes 'summary' parameter as optional but no description explains what format it accepts (free text, structured? max length?), whether it persists, or how it is returned by check_subagent_status.
No error classification or recovery guidance. The source code does not show error handlers that tell the LLM whether failures are retryable, user-fixable, or fatal. An agent cannot decide whether to retry, ask the user, or abort.