Loading ToolBench
MCP server for Entente — provenance engineering for coding agents. Provides tools for agent task management, contract negotiation, evidence submission, and checkpoint maintenance in a multi-agent relay network.
relayd exposes 19 specialized tools for a multi-agent task orchestration system. While tool names follow verb_noun conventions (checkpoint, propose_delta, await_contract), descriptions are domain-specific and often assume deep familiarity with the 'relay' contract model. Most tools lack visible input schemas in the provided source excerpt, only checkpoint shows partial schema. Parameter descriptions are sparse or missing entirely. Output schemas are undocumented. Error handling guidance is absent. The server implements a sophisticated protocol but prioritizes domain semantics over LLM-friendly definitions.
Answer clarification questions from a recipient agent (planner tool only).
Ask the human a question and wait for their response (planner tool only).
Wait for human answers to questions (planner tool only).
Long-poll for a contract version newer than since_version (after clarification). Returns pending on timeout; call again.
After relay_report_blocker: wait (up to timeout_s) for the human's reply. Returns pending on timeout (call again) or none when there is no outstanding blocker.
Wait (up to timeout_s) until another task (typically your subtask) reaches completed / failed / canceled; returns pending with its states on timeout (call again). You cannot await yourself.
Long-poll for the verdict of an attempt: verified, a delta repair contract, failed_budget, escalated, or pending (call again).
Input schemas missing or not visible for 14 of 19 tools. Only checkpoint and propose_delta show partial schema definitions; get_context, get_contract, respond_to_contract, report_progress, report_blocker, find_agents, submit_evidence, propose_task, revise_task, answer_clarification, ask_human, await_answers have no visible schema.
Descriptions are domain-jargon-heavy and assume familiarity with 'relay' contract model. Terms like 'checkpoint', 'proposal_id', 'expected_revision', 'contract_version' are not explained for LLMs unfamiliar with the system. Descriptions lack WHEN-to-use guidance and prerequisites.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Maintain your reusable checkpoint during work. Read/update your own facts, inspect pending child proposals, explicitly accept/reject them using expected_revision. No model summarization occurs here; facts are contextual claims, not verified evidence.
Agents that have worked in this repository and the sessions that still remember it, with the tasks they completed and the paths their contracts allowed. Pass a free agent's session_id as reuse_session to relay_propose_subtask to give it the work instead of spawning one that knows nothing. Facts only: what relayd verified and what the contracts allowed, never what an agent said about itself.
Retrieve specific IDs or tags from the checkpoint assigned to your contract. Bounded deterministic lookup returns revision, missing IDs, omissions and source freshness. Use for missing context instead of rereading the repository.
Return the current version of your task contract, your worktree and any active repair contract.
Return incremental findings to your assigning agent. Proposals do not change accepted checkpoint facts until the owner reviews them. Use the latest retrieved checkpoint base revision.
Delegate a separable unit of your task as a new contract you are the sender of (same mission, parent_task = you). Pass reuse_session (from relay_find_agents) to give the work to an agent that has already worked in that code rather than one that knows nothing. Linted like any contract; its allowed_paths must be disjoint from yours and it may not depend on you. Lint errors are returned so you can fix and re-propose with the same id.
Propose a new task to the planner (planner tool only).
Report that you are blocked, on what, and who you are waiting for.
Report a progress message (and optional percent).
Accept, ask for clarification on, or reject the contract. Accepted responses need interpretation and verification_plan; needs_clarification needs questions.
Revise an existing task (planner tool only).
Submit your claimed status per criterion and a summary. relayd collects the diff and runs every check itself.
Output schemas are completely undocumented. No tool description specifies what fields are returned, their types, or structure. LLMs cannot plan downstream tool calls or extract required data without guessing.
No error handling guidance. Tools like await_contract, await_reply, await_task, await_verdict return 'pending' on timeout but do not explain what the LLM should do next (retry? escalate? ask user?). No recovery paths documented.
Parameter descriptions are minimal or absent. Tools with parameters (checkpoint, propose_delta, await_contract, await_reply, propose_subtask, await_task, await_verdict) lack descriptions for fields like 'expected_revision', 'base_revision', 'proposal_id', 'decision', 'contract_version'. LLMs cannot infer meaning from names alone.