Skip to main content
Glama
chapmanjw

Rutherford MCP Server

by chapmanjw

debate

Resolve contested questions by orchestrating multiple AI agents to argue in rounds, returning a full transcript with optional convergence tracking and synthesis.

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 | max) asks every voice to spend more reasoning where it has a knob; max is accepted and clamped to each agent's ceiling. 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.2.0
  2. Removedv3.1.0
  3. Changed8 schema fields changedv3.0.2
    • addedInput schema / properties / carry_forward
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
    • removedInput schema / properties / files
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "items": {
      -        "type": "string"
      -      },
      -      "type": "array"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null
      -}
    • removedInput schema / properties / include_raw
      Removed value: -{
      -  "default": false,
      -  "type": "boolean"
      -}
    • changedInput schema / properties / judge / anyOf
      Previous value: -[
      -  {
      -    "description": "A delegation target: a ``(cli, model)`` pair plus optional per-seat metadata.\n\nThe CLI alone is never the unit. Bring-your-own-model CLIs (OpenCode, Goose) expose many\nmodels through one adapter, and the same adapter may appear several times in a consensus\npanel with different models. ``model`` is ``None`` to mean the adapter's default model.\n\nThe metadata fields are all optional and default to ``None`` so a bare ``(cli, model)`` target\nis unchanged on the wire: ``role`` overrides the tool-level role for this seat, ``label`` is the\nkey the seat appears under in a result, ``weight`` and ``parity`` feed the consensus strategies,\nand ``stance`` steers the seat (taking precedence over a parallel stances list).",
      -    "properties": {
      -      "cli": {
      -        "type": "string"
      -      },
      -      "label": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "default": null
      -      },
      -      "model": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "default": null
      -      },
      -      "parity": {
      -        "anyOf": [
      -          {
      -            "type": "boolean"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "default": null
      -      },
      -      "role": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "default": null
      -      },
      -      "stance": {
      -        "anyOf": [
      -          {
      -            "description": "Optional per-target steering for a consensus panel.",
      -            "enum": [
      -              "for",
      -              "against",
      -              "neutral"
      -            ],
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "default": null
      -      },
      -      "weight": {
      -        "anyOf": [
      -          {
      -            "minimum": 0,
      -            "type": "number"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ],
      -        "default": null
      -      }
      -    },
      -    "required": [
      -      "cli"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {},
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / require_independent_judge
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
    • removedInput schema / properties / stances
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "items": {
      -        "type": "string"
      -      },
      -      "type": "array"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null
      -}
    • changedInput schema / properties / targets / anyOf
      Previous value: -[
      -  {
      -    "items": {
      -      "anyOf": [
      -        {
      -          "description": "A delegation target: a ``(cli, model)`` pair plus optional per-seat metadata.\n\nThe CLI alone is never the unit. Bring-your-own-model CLIs (OpenCode, Goose) expose many\nmodels through one adapter, and the same adapter may appear several times in a consensus\npanel with different models. ``model`` is ``None`` to mean the adapter's default model.\n\nThe metadata fields are all optional and default to ``None`` so a bare ``(cli, model)`` target\nis unchanged on the wire: ``role`` overrides the tool-level role for this seat, ``label`` is the\nkey the seat appears under in a result, ``weight`` and ``parity`` feed the consensus strategies,\nand ``stance`` steers the seat (taking precedence over a parallel stances list).",
      -          "properties": {
      -            "cli": {
      -              "type": "string"
      -            },
      -            "label": {
      -              "anyOf": [
      -                {
      -                  "type": "string"
      -                },
      -                {
      -                  "type": "null"
      -                }
      -              ],
      -              "default": null
      -            },
      -            "model": {
      -              "anyOf": [
      -                {
      -                  "type": "string"
      -                },
      -                {
      -                  "type": "null"
      -                }
      -              ],
      -              "default": null
      -            },
      -            "parity": {
      -              "anyOf": [
      -                {
      -                  "type": "boolean"
      -                },
      -                {
      -                  "type": "null"
      -                }
      -              ],
      -              "default": null
      -            },
      -            "role": {
      -              "anyOf": [
      -                {
      -                  "type": "string"
      -                },
      -                {
      -                  "type": "null"
      -                }
      -              ],
      -              "default": null
      -            },
      -            "stance": {
      -              "anyOf": [
      -                {
      -                  "description": "Optional per-target steering for a consensus panel.",
      -                  "enum": [
      -                    "for",
      -                    "against",
      -                    "neutral"
      -                  ],
      -                  "type": "string"
      -                },
      -                {
      -                  "type": "null"
      -                }
      -              ],
      -              "default": null
      -            },
      -            "weight": {
      -              "anyOf": [
      -                {
      -                  "minimum": 0,
      -                  "type": "number"
      -                },
      -                {
      -                  "type": "null"
      -                }
      -              ],
      -              "default": null
      -            }
      -          },
      -          "required": [
      -            "cli"
      -          ],
      -          "type": "object"
      -        },
      -        {
      -          "type": "string"
      -        }
      -      ]
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "items": {},
      +    "type": "array"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / track_convergence
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
  4. Addedv2.0.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It reveals persistent per-voice ACP sessions, refusal of unsafe safety modes, early stopping under convergence/stall, budget enforcement at round boundaries, stop_reason values, rollup behavior, persistence as a durable job, and async/sync modes. This is far beyond a minimal behavioral summary.

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?

The description is front-loaded with the core purpose and then structured around parameter groups, which is appropriate given 20 parameters. It is dense and occasionally reads as one long run-on passage, but nearly every sentence adds operational detail the agent needs. It could be tightened, but it earns its length given the tool's complexity.

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 the high parameter count, no annotations, and a real output schema, the description is remarkably complete: it explains the debate loop, termination conditions, budget behavior, persistence, async execution, and safety constraints. The only gaps are the few undocumented parameters (timeout_s, working_dir, external_tracking, require_independent_judge), which keeps this from being fully complete.

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 description coverage is 0%, so the description must explain the parameters itself. It does explain the vast majority of parameters: targets, panel, panel_overrides, rounds, judge, carry_forward, track_convergence, synthesize, safety_mode, role, effort, time_budget_s, on_budget, persist, and mode. A few remaining parameters such as timeout_s, working_dir, external_tracking, and require_independent_judge are not described, preventing a perfect score.

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 opens with a specific verb and resource: 'Have several ACP agents argue a question across rounds and return the full transcript.' This immediately defines the tool's unique function and separates it from single-agent siblings like delegate, plan, or review. It also reinforces the boundary by stating that write/propose work should be routed to delegate.

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?

The description gives clear usage context, including the read-only restriction and the explicit instruction to route write/propose work through delegate. It also explains async mode and directs users to job_status/job_result for polling, and references list_roles for personas. However, it does not directly contrast debate with the sibling consensus, which would have made the when-to-use guidance fully explicit.

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