Skip to main content
Glama
chapmanjw

Rutherford MCP Server

by chapmanjw

debate

Orchestrate multiple AI agents to argue a question across rounds, detect convergence or stall, and return the full transcript with a closing summary.

Instructions

Have several ACP agents argue a question across rounds and return the full transcript.

targets is a list of {cli, model} objects or cli / cli:model strings; a debate needs at least two. Or name a saved panel (with optional panel_overrides) for a stored roster instead of targets; they are mutually exclusive (rounds / judge stay call args). Each voice keeps ONE persistent ACP session across all rounds: round one is each voice's independent answer, and each later round shows a voice the others' latest positions and asks it to revise -- the agent remembers its own prior reasoning in-session, so only the delta is sent. carry_forward=true instead re-sends the FULL prior transcript verbatim each round (for a weaker session memory; bounded by time_budget_s). track_convergence=true asks each voice for a one-word verdict each round and stops early when the panel CONVERGES (a unanimous verdict) or STALLS (the decision holds for the configured tolerance); the outcome field reports the termination reason (converged / stalled / unresolved / budget / quorum_lost) and the final decision. synthesize=true (default) adds a closing summary; judge names a target to write it. A debate is read-only deliberation: a safety_mode beyond read_only (propose / write / yolo) is refused -- the voices run on persistent sessions in the working directory with no per-turn sandbox -- so route write / propose work through delegate (a single agent isolated in a worktree sandbox). role names a persona (see list_roles) prepended to the opening prompt every voice argues from. effort (low | medium | high | xhigh) asks every voice to spend more reasoning where it has a knob. time_budget_s is a wall-clock deadline for the WHOLE debate enforced at round boundaries: a round still in flight at the deadline is cut and the transcript so far is finalized (stop_reason="budget", with a rollup); on_budget is harvest | continue | resume (default default_on_budget; continue runs every round to completion). persist keeps the debate as a durable job (F2): a parent state.json plus the full transcript.md; None follows default_persistence, true / false force it. mode="async" runs the debate as a background job and returns a job_id (poll with job_status / job_result); mode="sync" awaits it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNosync
roleNo
judgeNo
panelNo
effortNo
promptYes
roundsNo
persistNo
targetsNo
on_budgetNo
timeout_sNo
synthesizeNo
safety_modeNo
working_dirNo
carry_forwardNo
time_budget_sNo
panel_overridesNo
external_trackingNo
track_convergenceNo
require_independent_judgeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description extensively covers behavioral traits: persistent sessions, round mechanics, carry_forward, convergence tracking, safety_mode refusal for write/propose, persistence, sync/async modes, budget handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with clear action, then structured into paragraphs covering mechanics, constraints, and options. Could be slightly more concise but well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (20 params, no annotations), the description is thorough: covers deliberation model, read-only nature, convergence, persistence, async mode, budget handling, and role system. Output schema exists but not required for completeness here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and description adds meaning for many parameters (targets, panel, rounds, judge, carry_forward, etc.). However, not all 20 parameters are explained (e.g., require_independent_judge, working_dir, timeout_s, external_tracking missing).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Have several ACP agents argue a question across rounds and return the full transcript' – a specific verb+resource. It distinguishes from siblings like 'delegate' for write/propose work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use and when-not: 'route write / propose work through delegate' and clarifies debate is read-only deliberation. Also explains panel vs targets and other decision points.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chapmanjw/rutherford-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server