Loading ToolBench
Approval-first MCP terminal control plane with bounded execution and signed receipts.
The server demonstrates solid fundamental quality with consistent naming conventions (all tools use verb_noun pattern: terminal_plan, terminal_approve, etc.), complete input schemas with type definitions, and clear parameter descriptions. All 8 tools have non-empty descriptions (average ~90 chars) and required/optional parameter declarations. However, output schemas are not documented in the visible code, parameter descriptions lack detail about format/constraints, and error handling guidance is minimal. The schema structure is well-formed but lacks depth, descriptions could be more actionable per the 50-200 char baseline for A-grade tools. Tool composition is excellent: each tool has single responsibility, and the approval-first pattern with signed receipts demonstrates sophisticated control flow design.
Explicitly approve a plan that requires confirmation.
Cancel the active command
Execute an approved terminal plan and return a signed receipt.
Pause the active command
Validate a command against the workspace policy and create a non-executing plan.
Retrieve a signed execution receipt
Resume a paused command
Output schemas not documented. No visible schema definitions for return types of any tool. LLMs cannot plan downstream calls or extract required fields without documented output structure.
Parameter descriptions lack actionable constraints. 'session_id' and 'plan_id' describe what they are but not format, length, or generation method. 'command' parameter for terminal_plan lacks guidance on allowed command syntax, dangerous patterns, or examples of valid input.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2025-06-18+ | v2 |
Create a controlled retry plan from an earlier command. The new plan must pass policy and approval again.
Error handling descriptions absent. Tool descriptions do not explain what errors can occur, when they are retryable, or what the LLM should do next. E.g., terminal_approve does not document what happens if the plan_id is invalid or if approval is denied.
Descriptions for pause/resume/cancel are sparse (50 chars). 'Pause the active command' is grammatically correct but does not explain semantics: Does it send SIGSTOP? Can paused commands be resumed? How long can they remain paused? Is pause idempotent?
No documentation of idempotency. Tools like terminal_approve and terminal_execute do not state whether repeated calls with the same plan_id are safe. Agents retry on failures, non-idempotent operations risk duplicate execution.