Loading ToolBench
AI Agent Orchestration Engine — spawn and command an army of AI agents with Roman military precision
Centurion has 19 tools with generally clear naming conventions (all verb-based) and complete parameter schemas. However, descriptions vary significantly in quality and depth. Most tools lack output schema documentation, and parameter descriptions are minimal. Error handling guidance is absent. The server shows moderate professionalism in tool design but falls short of production-grade quality expected for a complex orchestration system.
Add a century (agent pool) to an existing legion.
Broadcast a message/instruction to working agents. Supports targeting all agents, a specific legion, or a specific century.
Request cancellation of a task. Cancellation is best-effort; running agents cannot be interrupted mid-execution.
Disband (delete) a legion and terminate all its agents. This will stop all centuries and legionaries belonging to the legion.
Get macro-level fleet status including all legions, centuries, and legionary counts. Returns an overview of the entire Centurion fleet with legion details, century breakdowns, and hardware resource information.
Get details for a specific century including legionary counts and queue depth.
Missing output schema documentation for all tools. LLMs cannot predict response structure or plan downstream tool calls without documented return types.
Parameter descriptions are generic and lack specificity. For example, 'quota' in raise_legion says 'Optional resource quota dict with keys like max_centuries, max_legionaries, etc.', but does not specify exact key names, value types (int/float), or valid ranges. LLMs cannot validate input without precise constraints.
No error handling guidance in any tool description. Tools like disband_legion and remove_century are destructive but provide no recovery instructions if a user attempts an unintended deletion. Descriptions should guide: 'This action is permanent. Ensure the legion ID is correct before calling.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Get details for a specific legion.
Get details for a specific legionary by ID. Returns status, current task, and performance statistics.
Get details for a specific task by ID. Searches across all legions and centuries for the task.
Get hardware resources and scheduling state. Returns CPU, memory, and other resource information used by the Centurion scheduler for placement decisions.
List all registered agent types available for creating centuries. Returns names, class names, and module paths for each agent type.
List all legionaries (agent instances) in a century.
List all active legions with their status and century information.
Create (raise) a new legion.
Get hardware-aware deployment recommendation. Probes the system and returns suggested agent counts by type based on available CPU and memory.
Remove and dismiss a century, terminating all its legionaries.
Manually scale a century to a target legionary count.
Submit a batch of tasks distributed across a legion's centuries.
Submit a task to a specific century for execution.
Weak descriptions for read-only discovery tools. 'List all active legions with their status and century information' is functional but does not explain WHEN to call it relative to other tools. Should state: 'Call this first to discover available legions before targeting a specific one with add_century or submit_task.'
Mutual exclusivity and conditional parameter semantics not documented. For example, 'broadcast' accepts 'target' (all|legion|century) and 'target_id', but 'target_id' is only required when target != 'all'. LLMs may pass both unnecessarily or omit target_id when needed.
Parameter type inference required for complex nested objects. 'agent_type_config' in add_century is typed as 'object' with no schema for its internal structure. LLMs cannot construct valid config without examples or a detailed description of allowed keys.
No idempotency semantics declared. Tools like submit_task may or may not be idempotent, if an LLM retries on transient failure, will it create a duplicate task? Descriptions should state: 'Providing the same task_id ensures idempotent submission; omitting it generates a new task_id on each call.'
Tool chaining fields not guaranteed. For example, raise_legion describes creating a legion but does not confirm it returns 'legion_id', which add_century requires. If the response omits legion_id, the agent must call list_legions to find the ID, breaking the expected workflow.
Pagination not documented for list tools. 'List all active legions' and 'List all registered agent types' do not mention limits, offsets, or total counts. Unbounded lists risk context window exhaustion if a fleet contains thousands of legions.