Skip to main content
Glama

ask_debate

Run an adversarial AI debate on a hard-to-reverse software choice: one model proposes, another refutes, and a neutral model rules.

Instructions

DIRECTIONAL, ADVERSARIAL — pit two models AGAINST each other over a structured claims ledger, then have a fresh third model adjudicate. Unlike ask_council (N models vote independently) or ask_chain (each stage refines the last), the debate makes one model PROPOSE a position decomposed into load-bearing claims, the other REFUTE each claim (concede or contest-with-a-concrete-failure-scenario), the proposer REVISE under fire, and an anonymized adjudicator RULE on the merits. Reserve it for a genuinely contentious, hard-to-reverse SOFTWARE decision where you want the strongest case for AND against stress-tested — 'is this concurrency design sound', 'should we commit to approach X or Y' — not for questions with a clear answer. Pick the pair with proposer and opponent (e.g. proposer='fable', opponent='codex' for Fable vs GPT-5.6 Sol, or opponent='glm'); defaults to fable vs minimax. adjudicator picks who rules (default 'fable'; e.g. 'opus' for Claude Opus 5, or 'codex') — keep it off the debating pair so the ruling stays third-party. rounds is 1 (default) or 2 (adds a rebuttal pass). The server decides the outcome deterministically from the ledger — resolution is 'conceded' (opponent conceded everything), 'converged' (all contests resolved and both sides agree), 'adjudicated' (the adjudicator decided), or 'stalemate' (both dug in with nothing new → confidence is mechanically downgraded). Costs up to four sequential model calls, so it's the most expensive mode — use it sparingly. Degrades to a single-critic pass when the opponent is unconfigured. Same scope as ask: broad and conceptual engineering questions are fine; direct offensive-security asks and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Aliases: 'm3' = minimax, 'gpt' = codex, 'opus5' = opus.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roundsNo1 (propose→refute→revise, default) or 2 (adds a rebuttal pass before adjudication).
contextNoOptional code snippets, file paths, or structural context (seen by both sides).
sessionNoOptional coordination key for the cross-agent hub (`session_list` / `session_peek`). Reuse the same key across agents working the same decision so turns group together. Defaults to the tool name (`ask_council` / `ask_chain` / `ask_debate` / …) when omitted.
opponentNoModel that refutes it (default 'minimax'). Try 'codex' (GPT-5.6 Sol) or 'glm'.minimax
proposerNoModel that proposes the position (default 'fable'). Aliases: 'm3'=minimax, 'gpt'=codex.fable
questionYesA contentious, hard-to-reverse software/engineering decision to debate (e.g. 'is this concurrency design sound?', 'approach X or Y?').
adjudicatorNoModel that rules on the contested claims (default 'fable'; 'opus' for Claude Opus 5, 'codex' for GPT-5.6 Sol, …). It sees the ledger anonymized. Any council token works; keep it off the debating pair so the ruling stays third-party.fable
context_refNoKey(s) of context saved with `context_write` to pull in and prepend to `context`.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.12.0

TDQS

A4.8/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 behavioral burden and does so thoroughly. It discloses the deterministic resolution values ('conceded', 'converged', 'adjudicated', 'stalemate'), the confidence downgrade on stalemate, the cost of up to four sequential model calls, the degradation to a single-critic pass when opponent is unconfigured, and refusal scope for offensive security and non-software domains.

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 long but every clause earns its place given the tool's complexity. It is front-loaded with the directional/adversarial core and the sibling comparison before diving into parameters. It could be more scannable with bullet points, but the density of high-signal information justifies the length.

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?

For an 8-parameter tool with no output schema, the description is complete: it explains workflow, model role selection, defaults, aliases, outcome vocabulary, cost, fallback behavior, and allowed/refused domains. An agent has everything it needs to invoke ask_debate correctly and interpret its resolution, with no missing structural information.

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 100%, so the baseline is 3. The description adds genuine value over the schema: concrete model choices (proposer='fable', opponent='codex', adjudicator='opus'), alias resolution ('m3'=minimax, 'gpt'=codex, 'opus5'=opus), the strategic advice to keep the adjudicator off the debating pair, and the meaning of rounds. This goes beyond restating parameter types.

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, vivid verb phrase — 'pit two models AGAINST each other over a structured claims ledger, then have a fresh third model adjudicate' — and names the exact workflow (propose, refute, revise, rule). It explicitly contrasts with ask_council and ask_chain, so an agent can immediately tell this tool apart from its closest siblings.

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?

It says precisely when to use it: 'Reserve it for a genuinely contentious, hard-to-reverse SOFTWARE decision' with examples like concurrency soundness or approach X vs Y, and when not to use it: 'not for questions with a clear answer.' It also names alternatives (ask_council, ask_chain) and warns this is the most expensive mode, to be used sparingly, plus scope refusals.

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

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/baggybin/ask-fable'

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