Loading ToolBench
MCP coordination server that keeps parallel coding agents from stepping on each other
Tirith is a well-structured MCP coordination server with 21 tools covering claims, tasks, contracts, notices, decisions, memory, and messaging. Tool naming follows verb-noun conventions consistently (claim, release, task_pull, contract_publish, etc.). All tools have descriptions ranging 50 - 200 chars, meeting the 10 - 1024 char baseline. Every parameter has a description. Input schemas are properly defined with JSON Schema types (string, integer, boolean, array, enum). However, output schemas are not explicitly documented in the visible code, the server returns structured JSON with 'status' fields but no formal response schema definitions are visible. Error handling uses domain-specific status codes (ok, conflict, not_found, none, invalid) rather than MCP-level errors, which is good for recovery guidance. Most tools are single-responsibility (idempotent claim operations, pagination-aware list tools). Some tools like task_update include 'force' flags that could enable destructive behavior without confirmation patterns. Overall definition quality is solid but lacks documented output schemas and confirmation gates for destructive operations.
Claim paths in the repository before editing them. Returns a brief of unread notices, contracts, decisions and memory notes for those paths.
List live claims, filtered by agent, path, and pagination.
Get a contract's details by name, id, or id prefix.
List contracts filtered by path, kind, and pagination.
Publish or update an interface contract with shape, consumers, and version control.
List decisions filtered by path and pagination.
Record a decision about the codebase: why something was done a certain way.
Output schemas not explicitly documented in visible code. Tools return structured JSON with 'status' field but no formal response schema definitions (response shapes, field types, pagination metadata) are visible in tool registration.
task_update tool accepts 'force' parameter to take/close tasks another agent has in progress, but lacks confirmation gate or dry-run pattern. This enables destructive actions (force-taking another agent's work) without user confirmation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | <=2025-11-25 | v2 |
Return the full protocol guide for agents.
Read a memory note in full by id or title prefix.
Search memory notes by text, path, kind, and pagination.
Write a memory note: gotcha, lesson, or other observation about the codebase.
List messages sent to this agent, filtered by sender and pagination.
Send a message to another agent or all agents.
List notices filtered by path, kind, and pagination. Marks them as read.
Publish a notice about a change: rename, signature change, removal, or other.
Release claimed paths. Omit paths to release everything you hold.
Get the current state of claims, tasks, and other coordination data.
Create a new task with title, description, priority, dependencies, and affected paths.
List tasks filtered by status, owner, and pagination.
Pull the next available task with optional waiting for tasks to become available.
Update a task's status and add notes. Can force-take a task from another agent.
No explicit error recovery guidance documented in tool descriptions. Descriptions state what tools do but do not include guidance like 'If conflict, try release() first' or 'If not found, use claims_list() to discover available paths'.
Tools return domain-specific status codes (ok, conflict, not_found, none, invalid) rather than MCP error classification. While this works, the tool descriptions do not document which statuses are retryable, user-fixable, or fatal.
guide and state tools have generic descriptions ('Return the full protocol guide for agents' and 'Get the current state of claims, tasks, and other coordination data'). These lack specificity on WHEN to call them or what structured fields the response contains.