Loading ToolBench
A multi-agent orchestration platform with a dashboard and CLI for spawning, managing, and coordinating Claude Code, Codex, and Gemini CLI agents across projects
autonomOS provides 8 tools with complete input schemas and mostly good descriptions. Tool names follow verb_noun conventions (create_agent, list_agents, kill_agent, send, etc.). However, there are significant gaps in output schema documentation, parameter descriptions are sometimes vague, and error handling lacks recovery guidance. The server handles agent lifecycle management well but falls short of production-grade quality due to incomplete composition patterns and missing documentation for response structures.
Create a new agent — a dedicated CLI session with a name, context, and optional task. Defaults to Claude Code; set `provider` to spawn a Codex or Gemini agent instead.
Create a reusable agent template (blueprint) that defines a role, system prompt, and permission mode. Saved to ~/.autonomos/templates/.
Get the organization chart showing all agents and their hierarchy.
Terminate an active agent by name or session ID
List all active agents with their names, URIs, status, and working directories
List available agent templates (blueprints for creating agents with predefined roles).
Output schemas are undocumented across all 8 tools. Response structures are not specified, making it impossible for agents to know what fields to expect or plan downstream tool calls.
Parameter aliasing ('agent' and 'name' in kill_agent, set_manager) violates single-responsibility and creates ambiguity. Should consolidate to one canonical parameter name.
Irreversible operations (kill_agent, create_agent with bypass mode, create_template) lack confirmation/dry-run patterns. Agents need explicit warnings and a way to preview changes before committing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 75 | 2026-07-28+ | v2 |
Send a message to another agent. Use the from_uri from incoming messages to respond. Succeeds only if the destination accepted the message; any other result explains why it did not. Do not re-send a message reported as not-yet-delivered — a duplicate can make an agent act twice.
Set an agent's manager in the org chart. Both agents must be registered.
Error handling guidance is absent. Tools do not document what happens on failure (agent not found, invalid parameters, permission denied, network timeout). Agents cannot self-correct without recovery hints.
Tool descriptions are too brief for some tools (list_agents: 54 chars, list_templates: 88 chars). Descriptions should be 150-250 chars and include WHEN to use the tool, not just WHAT it does.
No pagination or result limits documented for list tools (list_agents, list_templates, get_org_chart). Large deployments could return hundreds of agents, exhausting context windows.
kill_agent description does not highlight the irreversible nature of termination. Agents must explicitly understand this is a destructive operation.
send tool lacks destination validation and error handling. What happens if 'to' URI is malformed or the destination agent doesn't exist? How does the agent know to retry vs. give up?