Loading ToolBench
A command and control (C2) server that enables remote task execution via PowerShell, allowing creation and monitoring of tasks through an MCP interface
ClaudeC2 exhibits severe quality gaps across all definition dimensions. Tool names are verb-prefixed but descriptions are bare (7-9 words), schemas lack comprehensive parameter documentation, and there is no output schema specification. Both tools accept parameters with minimal context. The server implements critical PowerShell command execution without proper input validation, error recovery guidance, or security hardening. Error handling returns generic messages that do not guide LLM recovery.
Check task status from C2 using PowerShell
Send task to C2 using PowerShell
Descriptions are critically underdeveloped. 'Send task to C2 using PowerShell' and 'Check task status from C2 using PowerShell' are 7 and 8 words respectively, well below the baseline 194-character average and fail to explain WHEN to use each tool, WHAT the tool returns, or prerequisites.
No output schema is documented. The tool implementations return dicts with 'status' and either 'response'/'result' or 'message' fields, but the agent has no visibility into what structure to expect. LLMs cannot plan downstream tool calls or extract chaining IDs without documented return types.
Parameter descriptions are missing entirely. 'command: str' and 'task_id: int' have NO description text beyond the type hint. Descriptions must explain what the parameter controls and what format is expected (e.g., 'The shell command to execute on the C2 client (e.g., whoami, ipconfig)').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
No input validation or error recovery guidance. create_c2_task accepts any string as 'command' and wraps it in PowerShell; check_c2_task accepts any integer as task_id. If the command is malformed, the tool returns a generic 'CalledProcessError' message. Error responses must tell the LLM what to do next (e.g., 'Invalid task_id: must be a positive integer. Call get_all_tasks to list valid IDs.').
Destructive tool lacks confirmation or dry-run. create_c2_task executes arbitrary shell commands via PowerShell on a remote C2 server, a classic destructive operation. There is no dry-run mode, no confirmation step, and no idempotency guarantee. An LLM mistake or prompt injection could lead to unintended command execution. Per pattern:confirmation-request, irreversible operations should support a confirmation workflow.
Hard-coded C2 server credentials (IP address and port) are embedded in the tool implementation ('http://192.168.1.61:8000/'). While not strictly a parameter leak, this violates the pattern:secret-injection principle, server addresses and credentials should be injected via environment variables or a secure config file, not hard-coded in source.
No output structuring or response field documentation. create_c2_task returns {'status': 'created', 'response': output} and check_c2_task returns {'status': 'completed', 'result': output}, inconsistent field names ('response' vs 'result') and no documentation of what 'output' or 'result' contains. Baseline pattern:response-shaper recommends returning typed objects with clear field semantics.
No dependency hints or tool chaining guidance. create_c2_task creates a task but does not document whether the caller must wait for check_c2_task to poll for results, what polling interval is recommended, or how to detect task completion. Per pattern:tool-chain, tool outputs should include IDs and references that enable seamless downstream calls.
No audit trail or permission gating. The tools execute commands on a C2 server without logging who invoked them, with what parameters, at what time, or with what result. Per pattern:audit-trail, agent-initiated actions must be traceable for compliance and incident response. Additionally, no permission checks exist to verify the calling agent has authority to execute commands.