Loading ToolBench
Local AgentOps for cross-vendor CLI agents: route work, recover state, and accept only with evidence.
Trinity-lite MCP exposes 6 tools with well-structured schemas, good naming conventions (verb_noun), and comprehensive parameter descriptions. All tools follow the action-verb pattern and are clearly differentiated by purpose. Descriptions are detailed and explain WHEN to use each tool vs alternatives. Tool annotations (readOnlyHint/destructiveHint/idempotentHint/openWorldHint) are present and correctly applied. However, output schemas are NOT documented, the responses are not formally specified, forcing LLMs to infer structure. Error handling guidance is minimal (no recovery hints or error categorization). Composition is strong: tools form a natural workflow (dispatch → status → proof), with clear responsibility boundaries. Security-wise, the server accepts cwd parameters that could enable path traversal if not validated internally; the code visible does not show validation. Overall a solid B-grade implementation with room for output documentation and error recovery guidance.
Create a durable task for one explicit Trinity agent and run one worker cycle for that agent. Use this when the caller already knows the target agent; use trinity_dispatch_auto when routing should choose the agent. This writes to the local task database and may execute the configured agent command; with wait=true it returns the final compact task or a timeout error.
Resolve the best Trinity agent with the local route table, create a durable task, and run one worker cycle. Use this when the caller has a task but should not pick the agent manually; use trinity_dispatch for an explicit target. This writes route evidence and task state to the local database and may execute the selected agent command; the result includes compact task and route metadata.
Recover the newest task submitted by one source agent when the task id is unknown. Use this after an interrupted MCP wait or lost client response, then call trinity_status for the returned primary task id. By default it skips secondary review children so the returned task is the user-facing parent; set include_reviews=true to inspect review tasks.
Run a multi-step Trinity workflow from a pipeline file or the built-in implement-then-review flow. Use this for work that needs sequencing, review gates, or multiple task records; use dispatch tools for a single agent task. This creates and updates local task records and may execute one or more configured agent commands; it returns pipeline or review-flow evidence.
No output schemas documented for any tool. LLMs cannot determine response structure, required fields, or chaining opportunities without explicit schema definitions.
Error handling completely absent. No guidance on recovery actions, error categorization (retryable vs fatal), or expected failure modes. E.g., trinity_dispatch_auto with no matching route, trinity_status with invalid task_id, or wait_timeout expiration.
cwd parameter accepts filesystem paths without visible validation. Risk of path traversal (../../../etc/passwd) or unintended directory operations if validation is insufficient. Validation guidance should be in parameter description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
Read one task's full evidence chain as a structured proof bundle: route, work result, review, verification, acceptance, and a stage timeline. Use this to audit or export why a task was accepted or blocked; stages without recorded evidence are returned as explicit nulls. This is read-only and does not write files or run workers; use the trinity-lite proof CLI command to write JSON and Markdown bundle files.
Read the current state, result, route evidence, and acceptance metadata for one task id. Use this after dispatch or orchestration to poll progress or recover a result after a timeout. This is read-only and does not run workers or mark messages as read; it returns a compact task object or task-not-found error.
trinity_orchestrate annotation questionable: marked STATEFUL_LOCAL_TOOL but may execute external agent commands (openWorldHint should be true). Mismatch between declared and actual behavior.
wait and wait_timeout parameters present in trinity_orchestrate but marked 'Reserved for wait-aware clients; pipeline workers run in-process.' Documentation contradicts parameter presence, confusing for LLMs.