Skip to main content
Glama
baggybin

ask-fable

by baggybin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ask_debate

Pit proposer and opponent models against each other to stress-test a contentious software decision, then have a third model adjudicate the contested claims and rule on the merits.

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.
trustedNoOperator-authorized. When true, the prohibited-use denylist runs in log-only mode: security vocabulary in the question AND in `context` is audited but does not block. Use for legitimate security-engineering work (PoC analysis, CVE research, binary hardening review) where the ask genuinely needs security terms. Takes effect ONLY when the operator has set ASK_FABLE_ALLOW_TRUSTED (env or config); otherwise the flag is ignored and the denylist still applies.
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(op="write", …)` to pull in and prepend to `context`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.18.0
    • changedInput schema / properties / context_ref / description
      Previous value: -"Key(s) of context saved with `context_write` to pull in and prepend to `context`."New value: +"Key(s) of context saved with `context(op=\"write\", …)` to pull in and prepend to `context`."
  2. Changed1 schema field changedv0.16.0
    • addedInput schema / properties / trusted
      Added value: +{
+  "default": false,
+  "description": "Operator-authorized. When true, the prohibited-use denylist runs in log-only mode: security vocabulary in the question AND in `context` is audited but does not block. Use for legitimate security-engineering work (PoC analysis, CVE research, binary hardening review) where the ask genuinely needs security terms. Takes effect ONLY when the operator has set ASK_FABLE_ALLOW_TRUSTED (env or config); otherwise the flag is ignored and the denylist still applies.",
+  "type": "boolean"
+}
  3. First observedv0.12.0

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the adversarial flow, deterministic ledger-based outcome with specific resolution values, degradation to a single-critic pass, and the cost of up to four sequential model calls. None of this contradicts the annotations, and it adds meaningful operational context.

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?

The description is long but dense and every sentence earns its place: mechanism first, then differentiation, usage, parameter guidance, cost, scope, and aliases. It is front-loaded with the core concept and avoids filler.

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 a complex multi-model tool with no output schema, the description is thorough: it explains mechanism, outcome resolution values, cost, failure/degradation behavior, scope exclusions, and parameter configuration. An agent has enough to decide when to invoke it and how to configure it correctly.

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?

Although schema coverage is 100%, the description adds real parameter semantics: examples for proposer/opponent, aliases, the default fable-vs-minimax pairing, the requirement to keep the adjudicator off the debating pair, and the meaning of rounds. This goes well beyond the schema's field names and defaults.

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 states a specific mechanism: pit two models against each other over a claims ledger, then have a third adjudicate. It explicitly contrasts with ask_council and ask_chain, making the tool's identity and unique role unambiguous even before opening the schema.

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 gives clear when-to-use guidance ('genuinely contentious, hard-to-reverse SOFTWARE decision') and explicit when-not-to ('not for questions with a clear answer'). It also names alternatives, notes cost ('most expensive mode... use it sparingly'), and states scope limits such as refused offensive-security and non-software domain questions.

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

Deploy Server

Other Tools