Skip to main content
Glama
baggybin

ask-fable

by baggybin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ask_falsify

Grind contentious, checkable engineering claims down to evidence-backed survivors through structured assertion, adversarial attack, and mechanical receipt verification across persistent sessions.

Instructions

STATEFUL, ADVERSARIAL — a persistent falsification ledger, the process cousin of ask_debate. An assertor states typed claims; a falsifier (forced to a DIFFERENT lab) attacks them; and a deterministic CODE clerk — not a model — decides commit/kill/survive from receipts it verifies mechanically: a cite quote's VERBATIM presence in context, or a contra edge to a survived claim. A claim may speak, but it cannot compound (move reputation, count as consensus, survive) without a verified receipt — a fabricated or absent quote dies. State PERSISTS across calls under the REQUIRED session key, so a killed claim stays dead and calling again continues the same ledger. Use it to grind a contentious, CHECKABLE question down to what actually survives evidence rather than what sounds convincing — and pack the corpus the claims must cite into context/context_ref. Pick the pair with assertor (default 'minimax') and falsifier (default 'opus'); they must resolve to different labs. rounds is 1-6 assert->attack cycles per call (default 1). Returns the ledger's survived/killed/open/crucible split plus per-model reputation. Same scope as ask; offensive-security asks and non-software domains are refused. Receipts are cite and contra; with the operator opt-in ASK_FABLE_ALLOW_RUN=1 (and bwrap installed), a run: receipt executes a sandboxed Python snippet instead. metamorph: true adds a cold-restatement stability check. Aliases: 'm3' = minimax, 'gpt' = codex, 'opus5' = opus.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roundsNoAssert->attack cycles to run this call (default 1). Call again with the same `session` to advance the persisted ledger further.
contextNoThe corpus the claims must cite — code, specs, docs. `cite` receipts are checked for VERBATIM presence here.
sessionYesREQUIRED — the ledger's persistence key. Reuse it to continue the same falsification (a killed claim stays dead); a new key starts fresh.
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.
assertorNoModel that asserts claims (default 'minimax'). Aliases: 'm3'=minimax, 'gpt'=codex.minimax
questionYesA contentious, CHECKABLE software/engineering claim or question to grind down to what survives evidence (e.g. 'is this API idempotent as documented?').
falsifierNoModel that attacks the claims (default 'opus'). Must resolve to a DIFFERENT lab than the assertor — a model must not grade its own family.opus
metamorphNoAlso run a metamorphic stability check on unsupported claims: restate a claim (semantics-preserving) and re-ask the assertor COLD — a claim that flips is unstable and cannot compound; a stable one earns WEAK support (the only way a claim survives with no corpus to cite and no code to run). Costs 2 extra model calls per unsupported claim; stability is not truth, so stable-but-unverified survivors are reported separately as `stable_unverified`.
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. Addedv0.15.0

TDQS

A4.7/5.0
Behavior5/5

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

Describes non-obvious behavior: state persists across calls under the required `session` key, a killed claim stays dead, and a deterministic CODE clerk rather than a model decides outcomes. It also discloses the sandboxed code-execution path, the `trusted` flag's env-var dependency, and the metamorphic stability check — far beyond what annotations provide.

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 and dense, covering many behaviors, but it is front-loaded with the core adversarial-ledger concept and organized from mechanics to usage to advanced options. Some redundancy with schema parameter descriptions exists, yet most sentences earn their place given the tool's complexity.

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?

With no output schema, the description still specifies the return shape: 'survived/killed/open/crucible split plus per-model reputation.' It also covers security refusal, state persistence, model-lab constraints, sandbox execution, and advanced flags, making the tool fully understandable without external references.

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 substantial meaning: assertor/falsifier must resolve to different labs, aliases like 'm3'=minimax, `context` must contain the corpus for verbatim receipt checking, `rounds` semantics, and `metamorph` costs extra model calls and yields `stable_unverified`. This is rich, non-redundant parameter context.

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: 'a persistent falsification ledger' where an assertor states claims and a falsifier attacks them. It distinguishes itself from siblings by explicitly naming ask_debate as its 'process cousin' and declaring 'Same scope as ask'.

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 when-to-use guidance is given: 'Use it to grind a contentious, CHECKABLE question down to what actually survives evidence.' It also states exclusions (offensive-security asks and non-software domains are refused) and names ask_debate as a relative. However, it does not fully articulate when a sibling like ask_debate should be preferred over 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

Other Tools