Skip to main content
Glama

ask

Sanity-check code structure, data flow, or a design trade-off with an AI model: submit one specific question, paste relevant code, and receive a recommendation with confidence and follow-up.

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. ask_opus5 is this same tool on Claude Opus 5 — cheaper and faster; use it for high-volume or long back-and-forth work and keep ask for the hardest calls. Ask the Fable 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.
contextNoOptional code snippets, file paths, or structural context.
sessionNoConversation key. Reuse it to ask follow-ups (Fable keeps context); use a new key or reset=true to start a fresh topic.default
trustedNoOperator-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.
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_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. Dates show when Glama detected each change.

  1. First observedv0.12.0

TDQS

A4.9/5.0
Behavior5/5

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

With zero annotations, the description carries the full burden and delivers abundantly: the model 'has NO tools and CANNOT open files, so a bare file path is useless to it'; latency is stated ('Answers usually take 1-3 minutes'); refusal scope is enumerated (offensive-security and biology/medicine refused, while security code and CS are in-scope); and the response protocol is disclosed (sidecar, followup, context_exhausted status semantics).

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 (~300 words), but the density is largely justified by the tool's complexity: no annotations, no output schema, 6 params, and a nuanced interaction protocol. It is front-loaded with the default-move directive, though there is some redundancy in 'don't wait to be told and don't wait until you're stuck' immediately followed by the same idea in the next sentence.

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 high-complexity tool with no annotations and no output schema, the description covers everything an agent needs: triggers, scope exclusions, context-passing rules, session semantics, latency, refusal boundaries, and the full response/followup protocol including `sidecar` and `context_exhausted`. The only aspects it omits (trusted, reset) are fully documented in the schema.

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%, but the description adds operational meaning the schemacannot: for context it mandates 'ALWAYS paste the real code... plus any error or failing test'; for question it prescribes 'ONE specific decision... or ONE generative prompt'; for session it explains multi-turn reuse; for context_ref it explains the paste-once-reference-many pattern tied to `context_write`. Only trusted and reset are left to the already-detailed schema descriptions.

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?

Spells out a specific verb+resource+domain: 'Ask the Fable 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.' It also distinguishes itself from a large sibling family by declaring itself the 'DEFAULT MOVE' and explicitly naming ask_opus5 as a different-capability variant.

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?

Gives explicit when-to-use triggers ('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') and precise routing: 'use ask_opus5... for high-volume or long back-and-forth work and keep ask for the hardest calls.' It also states when to stop using the tool entirely via the `context_exhausted` status: 'stop re-asking and use your own judgment.'

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