Loading ToolBench
Human-in-the-loop approval queue for agent-proposed side effects. Agents submit actions for human review; reviewers approve/reject via a web UI or inline elicitation. Approved actions execute on the agent side.
Strong tool naming (verb_noun pattern) and comprehensive input schemas with proper Zod validation. All 6 tools have descriptions and typed parameters with enums where appropriate. Output schemas are documented. However, parameter descriptions lack depth, most are 1-2 lines without guidance on when to use each tool, dependencies, or error recovery. Risk tier enum and idempotency key show good patterns, but descriptions don't explain the approval workflow or when elicitation vs. pending submission applies. Error handling is present but generic; no recovery guidance for common failures (e.g., 'decision not found').
Withdraw a still-pending proposal the agent no longer wants reviewed.
Look up the current status of a decision by id.
Run the side effect if (and only if) the decision is approved. Idempotent. Never runs twice.
Page through the decisions currently awaiting a human.
Submit an action and, if the client supports elicitation, ask the reviewer to approve or reject right now (and execute on approval). Otherwise leave it pending for the reviewer app.
Queue a proposed side effect for human approval. Returns a decision_id. Policy may auto-approve low-risk kinds.
Parameter descriptions lack actionable guidance. 'The action kind' and 'One-line summary' are minimal; no explanation of when to use submit_for_approval vs. request_approval, or how risk_tier affects approval flow.
Error handling is generic. No recovery guidance for common failures: decision not found, already executed, invalid kind, payload validation errors. LLM cannot self-correct without explicit error messages.
Tool descriptions do not explain the approval workflow or when elicitation is triggered. 'If the client supports elicitation' is vague, no guidance on what happens if it doesn't, or how to check client capabilities.
list_pending_approvals pagination is minimal. Cursor-based pagination is present but no guidance on how to iterate, or what happens when cursor is invalid/expired.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
No tool composition guidance. Descriptions don't explain the typical workflow: submit → check_decision → execute_if_approved. LLM must infer the sequence.