Skip to main content
Glama

Review a draft answer

ask_verify

Review an existing draft answer against source material and return objections a reviewer could prove, separated from unsupported opinion, so you know which critiques are evidence-based.

Instructions

Review a draft answer that ALREADY EXISTS — yours, another model's, or another tool's — and get back the objections a reviewer could actually SHOW, separated from the ones it could only argue.

This is the only mode that takes a finished answer as input. Every other mode reasons from scratch: ask_council fans a question out, ask_debate grows its own position, ask_falsify asserts its own claims. Reach for this when you have an answer in hand and the cost of it being wrong is high.

HOW TO READ THE RESULT. verify.prevented counts objections whose receipt code could check against your context or against a check that failed — those are the only ones that establish anything. verify.unbacked_objections counts argument without evidence: weigh it as opinion. A self-quoting verdict means every objection quoted the draft back at itself, which proves only that the reviewer read it — supply real source material in context and re-run.

WHAT IT DOES NOT DO. It never withholds or rewrites your draft; answer comes back unchanged on every path, including when the reviewer fails. And no objections is NOT a correctness guarantee — it means no fault was demonstrated, not that none exists.

Pass context (the source material a citation may quote) or the review can only produce opinion. Pass drafted_by to refuse a same-lab review. Costs one model call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
answerYesREQUIRED — the draft answer to review, as produced by another model, another tool, or you. It is returned unchanged; ask_verify never withholds or rewrites it.
contextNoThe SOURCE MATERIAL a `cite` receipt may quote — code, specs, docs. This is deliberately everything EXCEPT the draft: quoting the draft back at itself proves nothing, so without source material no citation is possible and the review can only produce opinion.
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.
questionYesThe question the draft answer was written for — what it was supposed to answer.
reviewerNoModel that reviews the draft (default 'opus'). Aliases: 'm3'=minimax, 'gpt'=codex.opus
drafted_byNoOptional — the model that WROTE the draft. When given, a same-lab review is refused: a family grading its own homework agrees with itself for reasons unrelated to the draft being right.
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. Addedv0.18.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations are thin (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false), so the prose carries the burden and it delivers. It discloses that the draft is never withheld or rewritten and comes back unchanged even on failure, that 'no objections' is not a correctness guarantee, that same-lab reviews are refused when drafted_by is set, and that it costs one model call. No contradiction with annotations.

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 tightly organized with a front-loaded mode definition followed by clear 'HOW TO READ THE RESULT' and 'WHAT IT DOES NOT DO' sections. For a tool with 8 parameters and no output schema, every block earns its place and nothing reads as 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?

With no output schema, the description properly takes on explaining result semantics: verify.prevented, verify.unbacked_objections, self-quoting verdict, the unchanged answer, and the no-guarantee caveat. It also covers the operational requirements (context, drafted_by) and cost, leaving no critical decision information to inference.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter already has rich descriptions, so the baseline is 3. The prose mostly restates what the schema says about context, drafted_by, and answer rather than adding new parameter-level meaning. The genuinely new content (prevented vs unbacked_objections, one-call cost) is output/cost semantics rather than parameter semantics.

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 ('Review a draft answer that ALREADY EXISTS...') and states the tool returns objections a reviewer could show versus only argue. It explicitly distinguishes itself from siblings by saying 'This is the only mode that takes a finished answer as input' and contrasting ask_council, ask_debate, and ask_falsify.

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 exactly when to use it ('Reach for this when you have an answer in hand and the cost of it being wrong is high'), names the alternatives, and explains why they differ. It also gives explicit preconditions: pass context or the review only produces opinion, and pass drafted_by to refuse a same-lab review.

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