Loading ToolBench
Multi-agent orchestration for AI coding agents with file locking, inter-agent messaging, plan coordination, and project graph analysis via MCP tools
Event Horizon presents a cohesive multi-agent orchestration tool suite with 14 well-named tools following verb_noun patterns. Descriptions are comprehensive and contextual, generally in the 150-300 character range, meeting baseline expectations. All tools have documented input schemas with type definitions and parameter descriptions. However, output schemas are not explicitly documented in the visible source, and error handling guidance is sparse. Tool naming is consistent and clear (eh_* prefix with action verbs: check_, acquire_, release_, list_, get_, claim_, update_, etc.). Parameter descriptions are detailed and include constraints. The server demonstrates good composition, tools are logically separated and designed for chaining (e.g., eh_claim_task returns task IDs that feed into eh_update_task). However, lack of output schema documentation and minimal error recovery guidance prevent a higher score.
Acquire an exclusive lock on a file. Returns success or failure with owner details.
Archive a plan — marks it as archived so it no longer shows as active. Tasks are preserved for reference.
Check if a file is currently locked by another agent. Returns lock status and owner info.
Atomically claim a task. If task_id is omitted or empty, auto-selects the best available task using the recommendation algorithm (requires agent_type).
Permanently delete a plan and all its tasks.
Get recent file activity across all agents. Shows which files were read/written, by whom, and when.
Output schemas are not documented in visible source code. Tools return structured data (lock status, agent info, plan tasks, messages), but the response field definitions, types, and required fields are not declared. This forces LLMs to infer output structure and risks misuse of returned data.
Error handling and recovery guidance is missing. Tools do not document what errors are retryable, what causes are user-fixable, or what recovery actions the LLM should take. For example, eh_claim_task may fail if no tasks are available or if the agent lacks the required type, but no recovery hints are provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Get a plan by ID, or the most recently loaded plan if no ID given. Returns all tasks with status, assignee, and dependencies.
List all AI agents currently connected to Event Horizon. Shows name, type, state, working directory, and active file locks.
List all plans with their status, task counts, and progress.
Load a plan from a markdown file. Parses task checklist into claimable tasks with dependencies.
Release your lock on a file so other agents can access it.
Send a message to another agent or broadcast to all. Messages persist until read. Delivery is also keyed to the recipient's stable alias (workspace + name from eh_list_agents), so the message still arrives if their session restarts with a new ID.
Update a task you own — mark progress, done, or failed. Add notes visible to other agents.
Wait until a file's lock is released, then acquire it. Blocks until available (max timeout).
eh_claim_task description does not clearly explain when agent_type is required. The description states 'Required when task_id is omitted for auto-selection', but does not explain what agent_type values are valid or what happens if auto-selection fails. LLMs may pass invalid agent types.
eh_load_plan accepts both file_path and content as alternatives, but the schema does not mark one as required_one_of. Both are optional in the schema, creating ambiguity about which parameter takes precedence if both are provided. Descriptions should state the precedence rule explicitly.
eh_wait_for_unlock is inherently blocking (max timeout 60 seconds). Descriptions lack guidance on when this tool is appropriate vs. when an agent should use polling (check_lock in a loop). No mention of cancellation semantics if the agent is interrupted.
eh_send_message description mentions 'stable alias' and worktree stability, but does not explain what happens if both to_agent_id and to_agent_name are omitted. The schema shows both as optional and not required, but the tool behavior is undefined if neither is provided.
Tools that list or search results (eh_list_agents, eh_file_activity, eh_list_plans) do not advertise pagination support in their descriptions. eh_file_activity accepts 'limit' parameter but no offset/cursor. If agent counts are large, no guidance exists for how to retrieve paginated results.
eh_delete_plan is marked DESTRUCTIVE but has no confirmation or dry-run mechanism documented. Agents may accidentally delete plans without explicit verification, violating pattern:confirmation-request.