Loading ToolBench
Multitasker has 6 tools with explicit registration in fastmcp and clear schemas. Naming is reasonable (verb_noun pattern with 'multitasker_' prefix), and all tools have descriptions. However, descriptions are inconsistent in quality, some contain implementation instructions (polling cadence) rather than pure tool documentation, and parameter descriptions are minimal. Input schemas are present and properly typed for all tools. Output schemas lack formal documentation. Error handling is present but generic. No sensitive data in parameters (good security posture). Tool composition is sound: each tool has one responsibility. The server follows current MCP patterns (fastmcp, tool annotations, stateless handling via ctx.session_id) but is STDIO-only, which caps protocol readiness severely.
MULTITASKER: Cancel a background task before completion.
MULTITASKER: Clean up workspace for a completed/merged task. Removes cloned repo directory.
MULTITASKER: List all tasks from this session. USE THIS FOR POLLING - call every 60 seconds after starting tasks until all_complete is true.
MULTITASKER: Get recent log output from a background task.
MULTITASKER: Start a background coding task. Returns immediately with run_id. IMPORTANT: After starting tasks, you MUST poll multitasker_list every 60 seconds until all tasks complete.
MULTITASKER: Get status of a single task. For polling multiple tasks, use multitasker_list instead.
Tool descriptions embed implementation guidance (polling cadence, workflow steps) instead of pure task documentation. Per pattern:tool-description, descriptions should state WHAT the tool does and WHEN to use it, not prescribe how the agent should orchestrate calls. Move polling instructions to system prompt or capabilities metadata, not tool descriptions.
Output schemas are not formally documented. multitasker_run, multitasker_status, multitasker_logs, and multitasker_list return dict[str, Any] without inline schema documentation. Per pattern:tool, LLMs need explicit output field definitions to plan downstream calls. Return types should be typed and documented.
Parameter 'lines' in multitasker_logs has no constraints. Unbounded integers invite LLM to pass absurd values (e.g. 1 million lines) causing timeout or memory exhaustion. Per pattern:constrained-input, specify min/max range (e.g. 1 - 1000, default 200).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter 'limit' in multitasker_list has no constraints. Unbounded integers invite expensive full-table scans. Per pattern:constrained-input, specify min/max (e.g. 1 - 100) and document default behavior.
Error responses in multitasker_status and multitasker_logs return bare {'error': '...'} without guidance on next steps. Per pattern:recovery-guide, error responses should indicate whether the agent should retry, ask the user, or call a different tool.
Tool descriptions for multitasker_cancel and multitasker_cleanup do not explicitly state these are DESTRUCTIVE operations. Per pattern:command-tool, state-modifying tools must declare their irreversibility in the description so agents know not to call them speculatively.
No dry-run or confirmation pattern for destructive operations. Per pattern:confirmation-request, irreversible tools like multitasker_cleanup should support a dry-run flag or require explicit confirmation to prevent accidental data loss.
STDIO transport only. Per spec, STDIO servers are not remotely accessible and cannot integrate with hosted MCP clients. No way for external systems to invoke these tools.