Skip to main content
Glama
baggybin

ask-fable

by baggybin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ask

Submit a focused software-engineering question with code context to receive AI reasoning on structure, data flow, design trade-offs, and bug analysis.

Instructions

YOUR DEFAULT MOVE on anything non-trivial — use it liberally and early, don't wait to be told and don't wait until you're stuck. Reach for it BEFORE you guess at unfamiliar code, an API, or a library's behavior; whenever you weigh a design or refactor trade-off; when a bug isn't fully understood; or to have a strong reasoner sanity-check a plan or diff before you commit it. One well-framed ask with the code attached beats several bare ones. Set oracle="opus" for this same tool on Claude Opus (newest) — cheaper and faster; use it for high-volume or long back-and-forth work and keep the default Fable for the hardest calls. Ask the selected model to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. For questions about EXISTING code, ALWAYS paste the real code into context — the actual function/file/snippet the question is about, plus any error or failing test. The model has NO tools and CANNOT open files, so a bare file path is useless to it. Conceptual/brainstorming questions need no context and are welcome. Frame each call as ONE specific decision ('should X or Y given constraint Z' beats 'thoughts on this code?') or ONE generative prompt ('give me 5 approaches to X, with trade-offs'). Reuse the session key to think through a problem over several follow-up turns instead of restating everything. Answers usually take 1–3 minutes. Broad and conceptual engineering questions — including brainstorming and ideas for future code — are fine. Refused only when the question itself directly asks for offensive-security work (exploit development, attack tooling) or non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope); questions about security-related code are normal engineering. The result carries a sidecar ({recommendation, confidence, needs_context}); when the model needs more, it returns a followup telling you exactly what to paste — paste those (or context_write them and pass context_ref) and re-ask on the SAME session, but first check followup.likely_already_pasted and RE-READ your own paste rather than resending it. A context_exhausted status means the model still can't answer after repeated tries — stop re-asking and use your own judgment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resetNoDump+clear this session before asking, starting a fresh conversation.
oracleNoWhich multi-turn model answers: 'fable' (default) or the Opus family — 'opus' tracks the newest Claude Opus, and 'opus5'/'opus55'/'opus48' name the same Opus session. Opus is roughly half Fable's price and faster, so prefer it for high-volume or long back-and-forth work. For a single-turn model use `ask_model(provider=…)`.fable
contextNoOptional code snippets, file paths, or structural context.
sessionNoConversation key. Reuse it to ask follow-ups (the model keeps context); use a new key or reset=true to start a fresh topic. Fable and Opus sessions are namespaced separately, so the same key on each is two independent conversations.default
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.
questionYesA specific question about concrete software code/architecture (structure, functionality, data flow, module/function relationships, routing).
context_refNoKey(s) of context previously saved with `context(op="write", …)` to pull in and prepend to `context` — so you paste a big codebase context ONCE and reference it by key across many asks instead of re-pasting. Missing keys are reported, not fatal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.18.0
    • changedInput schema / properties / context_ref / description
      Previous value: -"Key(s) of context previously saved with `context_write` to pull in and prepend to `context` — so you paste a big codebase context ONCE and reference it by key across many asks instead of re-pasting. Missing keys are reported, not fatal."New value: +"Key(s) of context previously saved with `context(op=\"write\", …)` to pull in and prepend to `context` — so you paste a big codebase context ONCE and reference it by key across many asks instead of re-pasting. Missing keys are reported, not fatal."
    • addedInput schema / properties / oracle
      Added value: +{
+  "default": "fable",
+  "description": "Which multi-turn model answers: 'fable' (default) or the Opus family — 'opus' tracks the newest Claude Opus, and 'opus5'/'opus55'/'opus48' name the same Opus session. Opus is roughly half Fable's price and faster, so prefer it for high-volume or long back-and-forth work. For a single-turn model use `ask_model(provider=…)`.",
+  "enum": [
+    "fable",
+    "opus",
+    "opus5",
+    "opus55",
+    "opus48",
+    "claude-opus-4-8",
+    "claude-opus-5",
+    "claude-opus-5-5",
+    "opus-4.8",
+    "opus-48",
+    "opus-5",
+    "opus-5.5",
+    "opus-55",
+    "opus4.8",
+    "opus5.5"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / session / description
      Previous value: -"Conversation key. Reuse it to ask follow-ups (Fable keeps context); use a new key or reset=true to start a fresh topic."New value: +"Conversation key. Reuse it to ask follow-ups (the model keeps context); use a new key or reset=true to start a fresh topic. Fable and Opus sessions are namespaced separately, so the same key on each is two independent conversations."
  2. Changed1 schema field changedv0.16.0
    • changedInput schema / properties / trusted / description
      Previous value: -"Operator-authorized. When true, the prohibited-use denylist runs in log-only mode: security vocabulary in the question is audited but does not block. Use for legitimate security-engineering work (PoC analysis, CVE research, binary hardening review) where the question 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."New value: +"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."
  3. Changed1 schema field changedv0.14.0
    • changedInput schema / properties / trusted / description
      Previous value: -"Operator-authorized. When true, the prohibited-use denylist runs in log-only mode: security vocabulary in the question is audited but does not block. Use for legitimate security-engineering work (PoC analysis, CVE research, binary hardening review) where the question genuinely needs security terms. The operator is responsible for authorizing this flag."New value: +"Operator-authorized. When true, the prohibited-use denylist runs in log-only mode: security vocabulary in the question is audited but does not block. Use for legitimate security-engineering work (PoC analysis, CVE research, binary hardening review) where the question 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."
  4. First observedv0.12.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations are sparse (openWorldHint=true, readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries the full burden and delivers. It discloses latency (1–3 minutes), refusal criteria, the sidecar return shape, the followup mechanism, context_exhausted status, session-keeping behavior, and the trusted flag's denylist semantics — far more than annotations provide. No contradiction with the annotations.

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

Conciseness2/5

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

This is a single unbroken paragraph of roughly 350 words with no sectioning, headers, or scannable structure. While the tool's complexity justifies length, the format forces an agent to parse a dense block of prose to find the key instructions. It is under-structured rather than genuinely concise.

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 tool this complex — 7 parameters, session semantics, sidecar/followup return behavior, refusal rules, and a security flag — the description is exceptionally complete. It even explains return values (sidecar, followup, context_exhausted) in the absence of an output schema, so nothing an agent needs to call it correctly is missing.

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 coverage is 100%, which sets a baseline of 3, but the description adds substantial meaning beyond the schema: it explains oracle value selection, instructs that context must contain real pasted code (since the model cannot open files), elaborates the session reuse semantics, details the context_ref workflow, and clarifies when the trusted flag actually takes effect. This materially helps the agent invoke parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies this as a tool that asks an LLM (Fable/Opus) to reason about software/engineering work, and it distinguishes itself from the sibling ask_model by explicitly noting 'For a single-turn model use `ask_model(provider=…)`.' However, the purpose statement is buried deep in a wall of text rather than stated up front, which slightly dulls its clarity.

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?

This is the description's strongest dimension. It gives explicit when-to-use guidance ('YOUR DEFAULT MOVE on anything non-trivial — use it liberally and early'), when-not-to-use guidance (refused content categories), and names concrete alternatives: ask_model for single-turn and the oracle/Opus variants for high-volume work. It even tells the agent what framing works ('should X or Y given constraint Z') versus what fails.

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