Loading ToolBench
Auditable multi-agent coordination for OpenCode — parallel agent fleets with P2P messaging, witnessed receipts, and quorum ratification. Who saw this, who approved it, prove it.
23 tools with complete schemas and descriptions, but quality is uneven. Naming is verb-forward and clear (create_fleet, send_message, cast_vote). Descriptions are present but often generic (10-50 chars, well below the 50-200 char LLM-optimized baseline). Parameter descriptions are minimal, most are 1-2 sentences restating the parameter name. No output schemas documented. Error handling is absent from descriptions. Tool-args.ts shows defensive input validation exists in implementation, but this is not reflected in schema constraints (no enums, no min/max bounds). The server addresses a real multi-agent coordination problem (P2P messaging, receipts, ratification) but the tool interface does not guide LLM reasoning about when to use each tool or what to expect in responses.
Acknowledge receipt of a message
Cast a vote in a ratification council
Compile and validate route candidates with observations and budget constraints
Create a new agent fleet with optional timeout configuration
Retrieve pending messages for an agent
Retrieve receipts for a fleet or agent
Get a work receipt for an agent action
Descriptions are too short (10-50 chars) to guide LLM tool selection. Baseline for A-grade tools is 50-200 chars. Most descriptions are bare restatements of the tool name (e.g., 'Retrieve pending messages for an agent' for get_inbox). No context on WHEN to use this tool vs. similar ones, WHAT the response contains, or WHAT happens on error.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does get_receipts return? Is there a receipt_id for use in other tools?). This forces agents to guess or make exploratory calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
List all saved fleet templates
List all active fleets
Open a new ratification council vote
Health check and version reporting
Plan speculative backlog for agent execution
Recommend a route for agent execution based on capabilities and constraints
Record a work receipt for an agent action
Register an agent in a fleet
Register a capability for an agent
Save a fleet configuration as a reusable template
Send a P2P message between agents
Spawn a new agent in a fleet with a role and prompt
Spawn a fleet from a saved template
Tally votes for a ratification
Verify the integrity of the receipts ledger
Write a witnessed receipt for an action
Parameter descriptions lack actionable constraints. No enums for constrained fields (e.g., message_type in send_message, role in register_agent). No min/max for numeric fields (timeout_ms, context_window). No format hints (e.g., 'ISO 8601 date' for timestamps). tool-args.ts shows validation exists in code, but schema does not expose constraints to LLMs.
No error handling guidance in tool descriptions. Agents do not know which errors are retryable, which require user input, or which are fatal. tool-args.ts shows validation (requireString, optionalNonBlankString) but error messages are not documented in the tool interface.
Tool composition unclear. Multiple tools operate on receipts (write_receipt, get_receipts, get_work_receipt, record_work_receipt) with overlapping names and unclear distinctions. LLMs will struggle to pick the right one. No documentation of which tools chain together or what IDs flow between them.