Skip to main content
Glama

ask_council

Need a cross-checked answer for a hard-to-reverse engineering decision? Ask several AI models the same question and get one synthesized response with consensus and disagreement signals.

Instructions

DIRECTIONAL — reserve this for a genuinely contentious or HARD-TO-REVERSE decision (architecture, concurrency, data model, public API, migration) where a single opinion isn't enough and you want several models cross-checked, or for divergent brainstorming where you want independent idea sets merged without losing distinct options. It's slower and heavier than ask, so DON'T reach for it on routine questions — default to ask, and use at most one council call per problem. Check quorum/degraded in the result: a 1-of-N answer is one opinion, not consensus. Ask several models at once the same SOFTWARE/ENGINEERING question, then get back one answer that Fable synthesizes by reconciling all of them (each raw answer is also returned under sources). By default asks Fable (whichever id is newest) + MiniMax (MiniMax-M3), plus DeepSeek (deepseek-v4-pro) when ASK_FABLE_DEEPSEEK_API_KEY is configured — cheap direct models are preferred and consulted first. Pass models to choose from ['fable','fable51','opus','deepseek','minimax','glm','gemini','codex','grok','kimi'] ('fable' tracks the newest Fable automatically and 'fable51' pins claude-fable-5-1 even after it stops being newest — they are the same model today, so naming both buys you nothing; 'opus' is Claude Opus 5 on the same OAuth session as Fable — always available, half the price; 'gemini'/'codex'/'grok'/'kimi' need their local CLIs; 'glm'/'deepseek' need API keys configured on the server). You can also add Ollama Cloud models as 'ollama:' tokens (e.g. 'ollama:qwen3-coder:480b-cloud', 'ollama:nemotron-3-ultra:cloud'); these are reached via a local signed-in ollama daemon by default (reported+skipped if unreachable). The group token 'twin' (aka 'twin flames') expands to BOTH Anthropic reasoners at once — fable + opus — so models=['twin'] is a dual Fable/Opus 5 invocation and models=['twin','minimax'] adds a third voice to it. Both ride the OAuth session, so it needs no provider keys and is the cheapest real second opinion available. Instead of listing models, you can pass a named tier: 'default' (fable+minimax, +deepseek when its key is configured), 'twin' (the twin flames, fable+opus), 'middle' (all of the above +opus+glm+gemini+codex+grok+kimi, cheap models first), or 'full' (+the configured Ollama Cloud models). The result carries a consensus signal ('strong' | 'partial' | 'divergent' | 'unknown') and material_disagreement computed from the panelists' recommendations, and each entry in sources shows that model's recommendation — so you can see WHO endorsed what, not just the merged answer. Panel answers are anonymized to the synthesizer to blunt self-preference bias. Pass synthesizer to have a different model adjudicate the panel (default 'fable'; e.g. 'opus' = Claude Opus 5, 'codex'/'gpt' = GPT-5.6 Sol via the local CLI, or 'atlas:openai/gpt-5.6-sol') — it falls back to Fable when unavailable or failing, and the result's synthesis block reports what actually ran. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoNamed council preset (used when `models` is omitted): 'default' = fable+minimax, +deepseek when its API key is configured; 'twin' = the twin flames, fable+opus — a dual Fable/Opus 5 invocation needing no provider keys at all; 'middle' = +opus+glm+gemini+codex+grok+kimi (cheap models first); 'full' = +the configured Ollama Cloud models (ASK_FABLE_OLLAMA_COUNCIL).default
modelsNoExplicit list of models to ask, from ['fable','opus','deepseek','minimax','glm','gemini','codex','grok','kimi'] (aliases: 'm3' = minimax, 'gpt' = codex, 'xai' = grok, 'opus5' = opus), plus any 'ollama:<model>' cloud token (e.g. 'ollama:kimi-k2.7-code:cloud') or 'atlas:<model-id>' token (e.g. 'atlas:zai-org/glm-5.2'). One entry may be the group token 'twin' (aka 'twin flames'), which expands to BOTH Anthropic reasoners — fable + opus — on the one OAuth session, so ['twin'] is a dual Fable/Opus 5 invocation and ['twin','minimax'] adds a third voice to it. Overrides `tier` when given. 'glm'/'deepseek', 'ollama:*' and 'atlas:*' require API keys configured on the server; unconfigured ones are reported and skipped, not fatal.
contextNoOptional code snippets, file paths, or structural context (shared by all models).
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.
questionYesA specific software/engineering question to ask the selected models; Fable then synthesizes their answers into one.
context_refNoKey(s) of context saved with `context_write` to pull in and prepend to `context` — paste a big context ONCE, reference it by key here. Missing keys are reported, not fatal.
synthesizerNoModel that reconciles the panel answers into one (default 'fable'). Any council token works: 'opus' (Claude Opus 5 — cheaper and faster than Fable), 'codex' (alias 'gpt', GPT-5.6 Sol via the local CLI), 'atlas:openai/gpt-5.6-sol', 'ollama:<model>', … It may also be a panel member — its own answer is anonymized and read last. If it is unavailable or fails, synthesis falls back to Fable (see `synthesis` in the result).

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 behavioral burden, and it delivers comprehensively. It discloses that the tool is slow/heavy, that `quorum`/`degraded` in the result may indicate a 1-of-N answer is only one opinion, that raw answers are returned under `sources`, that panel answers are anonymized to blunt self-preference bias, and that the synthesizer falls back to Fable when unavailable or failing. It also surfaces non-fatal failure modes: unconfigured models are 'reported and skipped, not fatal', and unreachable Ollama daemons are 'reported+skipped'. This is far beyond what the schema or 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 but front-loaded with purpose and usage, then progressively details model selection, tiers, result signals, and synthesizer behavior — a sensible structure for a genuinely complex tool. However, there is clear redundancy: the 'twin flames' expansion is explained multiple times (in the main body, in the models parameter semantics, and echoed in tier semantics), and the model list/alias explanations overlap heavily with the already-100%-covered input schema. It earns most of its sentences, but some trimming would improve signal density.

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 7 parameters, no annotations, and no output schema, the description is remarkably complete. It explains the result shape (consensus signal, `material_disagreement`, `sources` entries with per-model `recommendation`, and a `synthesis` block reporting what actually ran), covers edge cases (unconfigured models skipped, Ollama unreachable, synthesizer fallback), and delineates the domain scope including refusals. An agent has enough information to invoke the tool correctly, interpret its results, and recover from failures without external documentation.

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?

Even though schema description coverage is 100% and the baseline is 3, the description adds substantial meaning beyond the schema. It explains model aliases and semantic subtleties ('fable' tracks newest automatically vs 'fable51' pins the version; 'twin' expands to both reasoners on one OAuth session), clarifies provider prerequisites ('gemini'/'codex'/'grok'/'kimi' need local CLIs; 'glm'/'deepseek' need API keys), details the `tier` presets ('middle' adds opus+glm+etc., cheap models first), and documents synthesizer fallback behavior. This materially improves an agent's ability to choose correct parameter values.

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 clear directive: 'reserve this for a genuinely contentious or HARD-TO-REVERSE decision' and immediately names the resource (a council of models) and the action (asking several models, synthesizing one answer). It explicitly differentiates from 'ask' by stating it is 'slower and heavier' and for multi-opinion cross-checking rather than routine questions. This is a specific verb+resource+scope definition that tells an agent exactly what the tool is for and what it is not for.

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?

The description provides explicit when-to-use guidance ('genuinely contentious or HARD-TO-REVERSE decision', 'divergent brainstorming'), explicit when-not-to-use guidance ('DON'T reach for it on routine questions — default to ask'), and even a dosage constraint ('use at most one council call per problem'). It also names the sibling alternative directly ('default to `ask`') and clarifies scope boundaries relative to `ask` ('Same scope as `ask`; direct offensive-security asks... are refused').

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