Loading ToolBench
MCP server exposing a dual-agent harness: Claude Code + Copilot CLI joined by a shared nervous system for task coordination, dispatch, and consensus-based code review
Strong tool design with clear naming (verb_noun pattern), comprehensive parameter schemas using Zod, and consistent descriptions. All 21 tools have explicit registrations with inputSchema and descriptions. However, output schemas are not formally documented, responses are inferred from code (json/text/fail helpers). Parameter descriptions are solid but some lack actionable constraints (e.g., task_id format, job_id structure). Error handling is present but generic in places. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classification in metadata.
Attach a file, code snippet, or other artifact to a task.
Add a checklist item the work must satisfy. Requirements are shown verbatim to the reviewing agent, so state them so they can be checked rather than interpreted.
Hand a task to an agent or to the human.
Open a task on the shared board so the work is visible and ownable.
Send a bounded task to the other coding agent and get its result back. The dispatched agent runs read-only (Read/Grep/Glob only).
See what the other agent has been doing. Check this before starting work.
The task rendered as one document: description, instructions, requirements checklist, and attachments. Read this before starting work — it is what you will be reviewed against.
Output schemas not formally documented. Tools return json/text/fail responses, but LLMs cannot see the structure of returned objects (e.g., what fields does get_task return? What is the shape of get_activity?). This forces LLMs to infer structure from context.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Server metadata marks tools as READ_ONLY or WRITE, but these are not exposed in MCP tool definitions. LLMs cannot see which tools are safe to retry or which modify state.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | <=2025-11-25 | v2 |
Read recent messages from the shared chat.
Poll a job created by dispatch(mode: "async").
Read the shared scoreboard tracking proposal outcomes and review quality.
Read one task in full, including its notes and any reviews.
List tasks on the shared board, newest activity first.
Post a message visible to the human and the other agent in the shared chat pane.
Remove an attachment from a task.
Remove a requirement from a task.
Set which agent receives unaddressed chat messages.
Replace the long-form instructions on a task: constraints, background, how to verify. Does not touch the one-line description.
Mark a requirement met or not met. Ticking one is a claim the reviewer will check, not a way to close the task.
Propose that a task is finished. The other agent reviews it; only its approval closes the task.
Review a proposal from the other agent. Approve it to close the task, or request revision.
Change a task's status or add a note. Note: you cannot set "done" here — that requires the other agent's approval via submit_proposal.
Resource IDs (task_id, job_id, requirement_id, attachment_id) lack format documentation. Descriptions do not specify whether IDs are UUIDs, integers, or opaque strings, or how to obtain them. This forces LLMs to guess or infer from context.
Error messages are generic. dispatch() returns 'dispatch to {target} failed: {err.message}' without guidance on recovery. No distinction between retryable (timeout) vs user-fixable (invalid task) vs fatal errors.
STDIO transport only. Server is not remotely accessible and cannot be used by hosted MCP clients. Limits deployment to local/CLI-only scenarios.