Skip to main content
Glama

ask_chain

Thread a question through ordered AI pipeline stages that draft, critique, and refine prior answers. Best for sequential refinement such as cost-tiered drafting or draft-to-red-team-to-decide.

Instructions

DIRECTIONAL, SEQUENTIAL — the relay counterpart to ask_council. Where the council asks N models the SAME question in parallel and synthesizes their independent answers ('what's true?'), the chain threads a question through an ORDERED pipeline where each stage refines the last ('make this answer better'). The operator sets the order as a pipeline string like 'm3 > glm > deepseek > fable' (or an ordered models array). Stage 1 drafts; each middle stage is told to solve independently and CRITIQUE the prior draft before extending it (an anti-anchoring guard); the final stage DECIDES, seeing all prior stages as anonymized peers. Best for two things a council can't do: cost-tiered escalation (a cheap/fast model does the legwork, Fable finalizes) and explicit draft → red-team → decide pipelines. Costs MORE latency than a council (stages run sequentially, not in parallel), so reserve it for when the ordered refinement is the point. Draft → critique → refine is also a natural IDEATION pipeline: a cheap model brainstorms broadly, later stages prune and sharpen the ideas. Order matters and repeats are allowed ('fable > glm > fable' = draft, critique, re-decide). A mid-chain model that refuses/errors is skipped (recorded); if the final stage fails, Fable synthesizes the survivors. The result carries a recommendation_drift trail and material_drift flag — the chain analogue of the council's consensus signal — so you can see whether the answer was refined or just rubber-stamped. Same scope as ask: broad and conceptual engineering questions (including brainstorming) 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, 'opus5' = opus. Any stage can be 'opus' (Claude Opus 5) — a cheaper, faster terminus than Fable, e.g. 'm3 > opus'. The group token 'twin' (aka 'twin flames') expands in place to two stages, fable then opus, so 'm3 > twin' is a cheap draft finished by both Anthropic reasoners in turn. Default pipeline if none given: minimax > fable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelsNoThe ordered pipeline as an array (alternative to `pipeline`), e.g. ['minimax','glm','fable']. Order-sensitive; duplicates allowed.
contextNoOptional code snippets, file paths, or structural context (seen by every stage).
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.
pipelineNoThe ordered pipeline as a string, e.g. 'm3 > glm > deepseek > fable'. Split on '>'. Order matters and repeats are allowed. Aliases: 'm3' = minimax. The group token 'twin' (aka 'twin flames') expands in place to two stages, fable then opus — positionally, so a member you also name elsewhere in the pipeline runs twice (repeats are legitimate here and are not collapsed). Ignored when `models` is given.
questionYesA specific software/engineering question to thread through the pipeline.
context_refNoKey(s) of context saved with `context_write` to pull in and prepend to `context`.

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 no annotations provided, the description carries the full burden, and it delivers thoroughly: it explains the sequential stage mechanics, the anti-anchoring critique step, mid-chain failure skipping, final-stage fallback to Fable, the recommendation_drift/material_drift output signals, and the default pipeline when none is given. This is exactly the behavioral context an agent needs beyond structured fields.

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?

Although long, the description is front-loaded with the core distinction, then flows naturally through mechanism, use cases, trade-offs, edge cases, aliases, and defaults. Every sentence carries distinct information — the ideation note, failure behavior, drift signals, and twin expansion are all non-redundant. Given zero annotations, the length is justified and well-structured.

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 with 6 parameters, no annotations, and no output schema, the description covers the full calling context: what it does, when to use it, expected cost/latency, failure behavior, result signals, aliases, default pipeline, and scope restrictions. An agent would know how to invoke it correctly and interpret the outcome at a sufficient level. The only minor omission is a full return-shape description, but the drift signals are mentioned, and the schema-less context makes this adequate.

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

Parameters4/5

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

Schema coverage is 100% and each parameter already has a detailed description, so the baseline is 3. The tool description adds value beyond the schema by giving a concrete pipeline example ('m3 > glm > deepseek > fable'), clarifying the default pipeline ('minimax > fable'), and explaining why order matters semantically (draft → critique → decide). It does not dwell on context/context_ref, but the schema already covers those sufficiently.

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 opening line 'DIRECTIONAL, SEQUENTIAL — the relay counterpart to ask_council' immediately names the verb, resource, and mode, and the next sentence draws an explicit contrast with ask_council ('parallel vs ordered pipeline', 'what's true?' vs 'make this answer better'). A reader can distinguish it from siblings instantly, without opening any 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 explicitly states 'Best for two things a council can't do: cost-tiered escalation ... and explicit draft → red-team → decide pipelines' and also warns 'Costs MORE latency than a council ... so reserve it for when the ordered refinement is the point.' It even gives scope exclusions ('direct offensive-security asks and non-software domain knowledge... refused'), giving an agent clear selection criteria versus ask_council and other siblings.

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