Loading ToolBench
Military-grade orchestration for Claude Code. Command. Conquer. A command-and-control (C2) server for managing a fleet of AI agents with MCP tools for checkin, orders, reports, handoffs, and roster management.
Six tools with complete schemas and descriptions, but quality is uneven. All tools have input schemas with proper Zod validation and enum constraints (strong). Descriptions are present but generic and lack actionable context (e.g., 'Check in with C2 command' doesn't explain WHEN to call it or what happens next). Parameter descriptions are minimal, most are 1-2 sentences with no format guidance, constraints, or dependency hints. No output schemas documented. Error handling is absent from tool definitions. No tool annotations (readOnlyHint/destructiveHint). Naming is verb-first and clear (checkin, check_orders, submit_report), but some names are ambiguous: 'get_context' could mean many things; 'send_handoff' mixes 'send' (communication) with 'handoff' (state transfer). No pagination, no result limits documented. Composition is reasonable, tools are single-purpose, but responses are unstructured JSON dumps, forcing LLMs to parse raw API output.
Check for pending orders from C2 command.
Check in with C2 command. Report your current status.
Get your unit state and any pending orders. Use at startup for situational awareness.
Get the fleet roster with all unit callsigns and details.
Hand off work to another fleet unit. C2 command is auto-notified.
Submit a report to C2 command (SITREP, INTREP, SPOTREP, or REQUEST).
No output schemas documented. Tools return raw JSON dumps (e.g., checkin, check_orders, get_context). LLMs cannot plan downstream calls or extract structured data without knowing response fields.
Parameter descriptions are minimal (1-2 sentences, no format guidance). E.g., 'files' in send_handoff is just 'Relevant files or paths', no indication of format (comma-separated? JSON array? file paths?). LLMs cannot validate input without explicit constraints.
Tool descriptions lack actionable context. 'Check in with C2 command' doesn't explain WHEN to call it (startup? periodic? on state change?), WHAT happens on success/failure, or WHAT the agent should do next. Descriptions should be 50-200 chars and answer: what, when, why.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
No error handling guidance in tool definitions. If checkin fails (invalid status, network error, unauthorized), the LLM has no recovery path. Error responses should categorize as retryable/user-fixable/fatal and suggest next steps.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe reads (check_orders, get_roster) from writes (checkin, submit_report, send_handoff) without explicit hints. This is a current MCP spec feature.