Loading ToolBench
Event-driven ZCode/OpenCode/Pi scheduling bridge for MCP clients. Bridges native agent transport protocols and manages concurrent run scheduling with resource conflict serialization.
The server defines 9 tools with schemas and descriptions, but quality is uneven. Most tools have adequate descriptions (100-300 chars), but several parameters lack descriptions entirely. Schemas are present and reasonably detailed (enums, required fields), but output schemas are only partially documented. Naming follows verb_noun convention (agent-start, agent-wait, agent-control) which is correct. However, parameter descriptions are inconsistent, some are excellent (e.g., 'threadId: Continue an existing session on its bound worktree'), others are vague or missing. No tool-level error handling guidance is visible in the definitions. The schema complexity suggests this is a sophisticated control plane, but the LLM-facing descriptions do not adequately explain WHEN to use each tool or what makes them distinct. For example, agent-observe and agent-wait both operate on runs but their distinction is not clearly explained for an LLM that must choose between them.
Create a new run branching from a checkpoint or message in a terminal run
Close a run or thread and release its resources
Get, set, list, or reset the selected backend for this connection
Inspect or compact the context of a run
Send control commands to an active run (guide, interrupt, or cancel)
Fetch events and state changes for an active run with optional server-side refresh
List sessions or adopt an existing thread to continue work
Inconsistent parameter descriptions. Many parameters have clear descriptions (e.g., 'prompt', 'threadId' in agent-start), but others are vague or missing context. 'refresh' in agent-observe is described as 'Refresh state from native runtime before returning' but does not explain WHEN an LLM should set this to true. 'action' in agent-control lacks guidance on when to use 'guide' vs 'interrupt' vs 'cancel'.
Unclear tool differentiation. agent-wait and agent-observe both monitor run state. The descriptions do not clearly explain: should an LLM use agent-wait for polling efficiency and agent-observe for detailed event history? The purpose and use-case distinction is buried and not LLM-friendly.
Output schemas not fully documented in tool definitions. RUN_OUTPUT_SCHEMA is defined in code but never referenced in tool descriptions. An LLM calling agent-start, agent-wait, or agent-observe has no way to know the exact fields returned (status, revision, threadId, phase, elapsedMs, result) or their types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
Start a new agent run with a prompt and optional configuration
Wait for changes to a run's status, blocking until a revision change or timeout
No error handling guidance in tool descriptions. Descriptions do not explain what errors are possible, how to recover, or what the LLM should do next if a call fails. Example: agent-start does not mention what happens if the backend is unavailable, credentials are invalid, or timeout is exceeded.
Parameter 'model' in agent-start requires nested 'providerId' and 'modelId' but does not explain how to discover valid provider/model pairs. An LLM cannot call this tool without knowing what providers and models are available, agent-config lists backends but does not return usable model metadata.
Conditional parameter relationships underdocumented. agent-start has mutually exclusive 'prompt' and 'goal' (mentioned only in description), but no explicit oneOf or allOf schema constraint. agent-control requires 'prompt' only for 'guide' and 'interrupt' actions but does not enforce this in the schema. Agents cannot reliably infer these rules from descriptions.
agent-recover description is vague: 'List sessions or adopt an existing thread to continue work.' Does it list all sessions in the system, or only sessions for the current user/workspace? What does the return value contain? An LLM cannot determine when to use this vs agent-start.
agent-close description says 'Close a run or thread and release its resources' but does not explain the difference between closing a run and closing a thread, or whether one cascades to the other. 'Release its resources' is vague, what happens to in-flight operations?
No idempotency or retry guidance. Tools like agent-start that create resources do not state whether they are idempotent. If an agent retries agent-start with the same parameters, will it reuse the existing run or create a duplicate?