Loading ToolBench
A multi-agent consultation system that coordinates AI agents (Claude, Codex, Gemini, Echo) to solve problems through fan-out and consensus mechanisms
Council provides 8 well-structured tools with complete JSON schemas, clear descriptions (avg 150 chars), and comprehensive parameter documentation. Naming follows verb_noun convention (council_start, council_poll, council_ask, council_cancel, council_list, council_read, council_write, council_status). All tools have input schemas with type definitions, enums, and constraints. However, output schemas are not documented in the source, responses are inferred from descriptions only. Error handling guidance is minimal; descriptions state what tools do but lack recovery hints for failure cases. Security is strong (vault-based access control, job_id patterns), but no tool annotations (readOnlyHint/destructiveHint) are present. Composition is clean: each tool has one responsibility, and tool outputs (job_id) chain into subsequent calls (council_poll, council_cancel).
Ask one agent and wait. Blocks up to ~110 s on the Claude Code CLI; on every other host it returns a job_id at 40 s. Long work: use council_start.
Cancel a running council job and kill its process tree. Idempotent; safe on a job that already finished.
List recent jobs. Returns a summary of the last N jobs, with optional filtering by state or backend.
Status and result of a council job. Blocks up to 45 s for a change, then returns progress or the answers. Call it until the state is terminal.
Read a file from the vault. Returns the file contents if the job has read permission.
Start a consultation with other AI agents (claude, codex, gemini, echo). Returns a job_id in under a second; then call council_poll.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns a job_id', 'Returns progress or answers') but no structured output schema is visible in the source. LLMs cannot plan downstream calls or extract fields without knowing the response structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). council_start, council_ask, council_write are state-modifying; council_poll, council_list, council_read, council_status are read-only. Annotations would help LLMs reason about side effects and retry safety.
Error handling lacks recovery guidance. Descriptions do not explain what to do if a call fails (e.g., 'If job not found, try council_list to verify job_id'). Error responses are not shown in the source.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Get server status and configuration. Returns version, mode, and available backends.
Write a file to the vault. Only available to jobs with write permission.
council_list and council_read descriptions are generic (70 chars). 'List recent jobs' and 'Read a file from the vault' lack context on when to use them vs alternatives or what structure they reveal.
council_status description is minimal (65 chars: 'Get server status and configuration'). Does not explain what fields are returned or when an agent should call it.