Skip to main content
Glama
chapmanjw

Rutherford MCP Server

by chapmanjw

consensus

Run the same prompt across multiple AI coding agents in parallel and aggregate their responses using strategies like majority or rank to reach consensus.

Instructions

Ask the same prompt of several ACP agents in parallel and reduce the voices.

targets is a list of {cli, model} objects or cli / cli:model strings; each runs as its own ACP session concurrently. Omit targets, pass an empty list, pass the sentinel "all", or set expand_all=true to fan out to every registered agent (each at its default model, capped at max_targets); the result's skipped field explains any agent left out. Or name a saved panel (with optional panel_overrides) to reuse a stored roster + strategy instead of targets; they are mutually exclusive (see reload_panels). A {cli, model} target may also carry per-seat role / label / weight / parity / stance. With a strategy other than all-voices (unanimous | majority | plurality | weighted | parity-pair | rank, optionally with a verdict_schema), each voice is asked for a verdict and the panel collapses to one outcome (StrategyResult) instead of every voice. rank is a two-round protocol (F4b): every voice answers, then ranks the OTHER answers anonymized and self-excluded, aggregated by Borda mean-rank into a rank leaderboard with a pairwise agreement matrix and concordance; require_dissent surfaces each non-winning position on its dissent. discount_correlated=true (F3 vote-math, opt-in) down-weights correlated votes by model-family lineage (vendor fallback) so a panel of "one model in N CLI costumes" counts as one effective vote under majority / plurality / weighted (each voice's lineage_weight shows it). Optional stances (parallel to targets) steer each voice and cannot combine with the auto-expanded panel. synthesize (defaults to synthesize_default, off out of the box) adds a server-side combined answer (all-voices only); judge names the seat that writes it. timeout_s applies to every voice; one failing voice is a failed result, never an aborted panel. Consensus is read-only deliberation: a safety_mode beyond read_only (propose / write / yolo) is refused -- there is no coherent merge of edits from several agents into one tree -- 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 prompt every voice receives. 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 panel (distinct from each voice's timeout_s): at the deadline answered voices are kept, in-flight ones cut, and the panel aggregates over the harvest if min_quorum usable remain (stop_reason="budget", with a rollup); below min_quorum is BUDGET_EXHAUSTED. on_budget is harvest | continue | resume (default default_on_budget). persist keeps the panel as a durable job (F2): a parent state.json linking a child record per voice, plus voices/voice-N.md artifacts; None follows default_persistence, true / false force it. mode="async" runs the panel 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
filesNo
judgeNo
panelNo
effortNo
promptYes
persistNo
stancesNo
targetsNo
strategyNo
on_budgetNo
timeout_sNo
expand_allNo
synthesizeNo
safety_modeNo
working_dirNo
time_budget_sNo
verdict_schemaNo
panel_overridesNo
require_dissentNo
external_trackingNo
discount_correlatedNo
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, so the description fully bears the burden. It details read-only nature (refuses write modes), timeout, budget, persistence, async/sync modes, and message aggregation logic. This goes well beyond minimal expectations.

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

Conciseness3/5

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

The description is very long and dense, covering many details. While front-loaded with the core purpose, it could be more scannable. The information is thorough but not concise; every sentence earns its place, but the length may overwhelm agents.

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

Completeness4/5

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

Given 24 parameters, no schema descriptions, and no annotations, the description covers most key aspects: safety, strategies, timeout, budget, persistence, async mode. The output schema exists, so return values are handled. However, a few parameter details are missing and the density might hinder quick comprehension.

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?

With 0% schema description coverage, the description explains almost all 24 parameters, including targets, panel, strategy, verdict_schema, judge, discount_correlated, stances, role, effort, etc. A few parameters like 'require_independent_judge' and 'external_tracking' are missing explanation, but overall it adds substantial meaning.

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 starts with a clear verb+resource statement: 'Ask the same prompt of several ACP agents in parallel and reduce the voices.' It distinguishes from siblings like 'delegate' (for writes) and other deliberative tools by focusing on parallel execution and reduction.

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

Usage Guidelines4/5

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

Explicitly states when not to use (write/propose work should go through 'delegate'), and provides guidance on using panels vs targets, strategies, and modes. Could further differentiate from 'debate' or 'plan', but the contrast with 'delegate' is strong.

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