Loading ToolBench
An MCP server that manages vassal processes and provides tools for executing commands, managing artifacts, auditing actions, and delegating control within a kingdom hierarchy
17 tools with complete schemas and descriptions, but quality is uneven. Most tools have adequate naming (verb_noun pattern) and descriptions (50-150 chars), but parameter descriptions are sparse or missing context. Output schemas are not documented. Error handling is minimal, most tools return generic error messages without recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Composition is reasonable: tools are single-purpose and chainable via IDs, but some tools like delegate_control and dispatch_task lack clear prerequisites or dependency hints.
Abort a pending or running task
Take full control of a vassal process. The King daemon will stop managing restarts for this vassal until delegate_release is called or this session ends.
Return control of a vassal back to the King daemon.
Show the current delegation mode of this MCP session. Reports whether a parent kingdom was detected and which vassals are currently delegated.
Dispatch a task to a vassal (typically a claude vassal) and return a task ID for polling
Execute a command inside a vassal's PTY session. NOTE: only works for process vassals (type: command/serial). For claude vassals use dispatch_task instead.
Output schemas not documented. Tools return JSON but LLMs cannot plan downstream calls without knowing response structure (e.g., what fields does list_vassals return? What is the shape of get_events results?). This forces LLMs to guess or make discovery calls.
Parameter descriptions lack actionable constraints. 'timeout_seconds' in exec_in has no min/max bounds; 'limit' in get_events has no default or range. LLMs may pass absurd values (timeout=999999, limit=1000000) that break the service.
Error handling is generic and non-actionable. Most tools return 'INVALID_PARAMS' or 'failed to X' without recovery guidance. E.g., 'vassal not found' should suggest 'Call list_vassals() to see available vassals.' This prevents agent self-correction.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
Retrieve a detailed action trace by trace ID, including all steps and outcomes
Retrieve audit log entries with optional filtering by action, vassal, or time range
Retrieve recent events from the kingdom event log
Retrieve serial events from a vassal's event stream with optional filtering
Poll the status of a dispatched task
Query real-time health guard status for vassal processes. Returns circuit breaker state, consecutive failure count, and the last check result for each configured guard. A circuit_open=true means AI modifications via delegate_control are currently blocked for that vassal.
List all vassal processes and their current status within the kingdom
Read a file from an allowed directory (kingdom root or vassal working directories) and return its content
Register a file-based artifact produced by a vassal
Resolve an artifact name to its file path and metadata
Respond to a pending approval request with an approval or rejection decision
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe reads from destructive writes without parsing descriptions. delegate_control, abort_task, and respond_approval are destructive but unmarked.
dispatch_task description lacks prerequisite hints. It says 'dispatch a task' but does not explain: What is a vassal? How do I know which tool names are valid? Must I call list_vassals first? This forces discovery overhead.