debate-hall-mcp

run_debate

Run an automated multi-perspective debate that explores alternatives, validates constraints, and synthesizes a resolution for complex topics.

Instructions

Auto-orchestrate a Wind/Wall/Door debate (ADR-0002).

Runs a complete automated debate with three agents:

Wind (PATHOS): Expands possibilities and explores alternatives
Wall (ETHOS): Validates against constraints and evidence
Door (LOGOS): Synthesizes a third-way resolution

Args: topic: The debate topic to explore tier: Configuration tier (default: "standard") thread_id: Optional custom thread ID (auto-generated if not provided) compression_tier: Override compression tier (None = use tier default) primer_tier: Override primer tier (None = use tier default) context_files: Optional list of absolute file paths to inject as codebase context. Agents will see file contents in their prompts. mode: Debate mode - "standard" for full Wind/Wall/Door debate, "speed" for lightweight Speed Dialogue Mode (Issue #139), "raci" for RACI governance mode (Turn Manifest Compiler). raci_config: Required when mode="raci". Dictionary with RACI roles: - responsible: Proposer role name (required) - accountable: Decision maker role name (required) - consulted: List of advisor role names (optional, max 5) - informed: List of observer role names (optional, max 3, post-verdict OBSERVATION turns)

Returns: Dictionary with thread_id, topic, status, turn_count, and synthesis

Input Schema

TableJSON Schema

Name	Required	Default
`mode`	No	standard
`tier`	No	standard
`topic`	Yes
`thread_id`	No
`primer_tier`	No
`raci_config`	No
`context_files`	No
`compression_tier`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Sep 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden, and it does well: it reveals that three agents run roles, that context files are injected into prompts, that raci_config is required for raci mode, and that the return value includes thread_id, status, and synthesis. It does not explicitly disclose side effects like thread persistence or whether a new thread is created, but the auto-generated thread_id strongly implies it.

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

Conciseness5/5

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

Despite covering many parameters and modes, the description remains well-structured and efficient. The one-sentence summary is front-loaded, followed by scannable bullets for agents, arguments, and return values. No sentence is redundant or filler.

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?

The description is complete enough to correctly invoke the tool: it covers all required parameters, mode-specific requirements, defaults, overrides, and return fields. Minor gaps remain, such as defining what values 'tier' accepts and explicit side-effect behavior, but the output schema and detailed argument docs make these non-blocking.

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

Parameters5/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 fully compensate, and it does. Each parameter is explained beyond the schema: context_files are 'absolute file paths' injected into prompts, mode explains all three options, and raci_config provides a detailed role dictionary with required and optional fields including max counts.

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?

States a specific verb and resource: 'Auto-orchestrate a Wind/Wall/Door debate (ADR-0002).' It goes on to name the three agents and their roles, making the tool's function unambiguous and distinct from manual debate helpers like init_debate or add_turn.

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?

Clear context is provided: this runs a 'complete automated debate' with three agents, implying it is the orchestration entry point rather than a step-by-step tool. It also explains when to use each mode ('standard', 'speed', 'raci'), but does not explicitly name alternatives or state when not to use this tool.

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

Deploy Server