ask-fable

by baggybin

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.12.0
Disambiguation3/5
The ask_* family — ask, ask_opus5, ask_m3, ask_glm, ask_deepseek, ask_gemini, ask_codex, ask_grok, ask_kimi, ask_ollama, ask_atlas, ask_openrouter — all share the same core purpose (single-model engineering reasoning) and differ mainly by backend, so an agent must read provider/credential details to choose correctly. Council variants and context/session/trace groups are more distinct, and the lengthy descriptions rescue most ambiguity, but the overlaps are real.
Naming Consistency4/5
Naming is strongly family-consistent: ask_<model>, ask_<provider>_council, context_<verb>, session_<verb>, trace_<verb>, list_<provider>_models, configure_<provider>_council. Minor deviations like bare 'ask', 'stats', 'reset_session', and 'context_pack' break the pattern slightly, but there is no style mixing and conventions are predictable within each subfamily.
Tool Count2/5
37 tools is well into the 'too many' band, largely because the same capability (ask one model, or ask a council) is reimplemented per provider instead of parameterized — 10+ single-model ask tools and 4 council tools carry heavy redundancy. Each tool is individually defensible, but the set is bloated and imposes a large navigation burden on agents.
Completeness5/5
The tool surface is thorough for its domain: single and multi-model asking modes (council, chain, debate), full context-store CRUD plus file packing, session listing/peeking/stats/reset, trace retrieval and runtime configuration, usage statistics, live model catalogs, and council configuration persistence. There are no obvious dead ends or missing lifecycle operations.
Average 4.5/5 across 37 of 37 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on September 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the basic read-only nature ('List'), the recency scope, and the 'without raw content' return limitation, but it leaves key behavioral aspects unexplained such as how 'correlated' is defined, ordering, pagination, and what fields are actually returned.
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 an efficient single sentence with a front-loaded verb and no filler. It is appropriately compact, though the brevity contributes to the lack of parameter and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 optional parameters, no annotations, and no output schema, this description is too thin. It supports a default unfiltered call but leaves nearly all filtering semantics, result shape, and correlation meaning to the agent's inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, and the description provides no parameter-level meaning. An agent cannot tell what 'before' refers to, what status values are accepted, or how 'session'/'provider' filter the correlated traces. The description adds no value beyond the bare parameter names.
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 states a specific action ('List') on a clear resource ('recent correlated tool traces') and explicitly notes the absence of raw content, which distinguishes it from sibling trace_get. Even without naming the sibling, the 'without raw content' qualifier tells an agent this is the metadata-oriented list counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for browsing recent trace metadata rather than retrieving full trace content, but it does not explicitly state when to prefer this over trace_get or other trace-related tools. There is no explicit when-not-to-use guidance or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load, and it does disclose the read-only nature and the ordered structure of the returned data. However, it does not explain truncation behavior, content inclusion, or what the response looks like beyond the high-level output.
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 a single well-formed, front-loaded sentence with no filler or redundancy. Every word contributes to identifying the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain more of the invocation context. It identifies what is returned but omits how max_chars affects the result, when include_content should be true, and what 'artifact references' concretely include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only implies trace_id via 'one trace'. max_chars and include_content are left entirely unexplained, and the description adds no semantic detail beyond what the parameter names already suggest.
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 states a specific verb ('Read') and a precise resource ('ordered events and artifact references for one trace'). It distinguishes trace_get from sibling tools like trace_list by emphasizing a single trace and its ordered event/artifact content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use trace_get instead of trace_list, context_read, or session_peek. The description implies use for reading a trace's details, but it never states selection criteria, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden, and it does well: it discloses a persistent write to ask_fable's config file, the env vars it overrides, the meanings of synthesizer values ('gpt' = local CLI, 'openai/gpt-5.6-sol' = Atlas-hosted, 'fable'), the built-in ladder on ommission, and the return value (saved config and file path). Minor gaps: it doesn't state whether an existing config is overwiritten or what happens if called with no arguments.
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 front-loaded with the core purpose, then organized into parameter meaning, usage prerequisite, and return value. It is dense with parentheticals but every clause adds necessary information for a tool without annotations or output schema. Slightly long, yet efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter, no-annotation, no-output-schema tool, the description covers the essential ground: what is saved, where it's written, what it overrides, how each parameter behaves, the omission fallback, and the return value. Missing edge-case details like overwrite semantics or validation of model ids are minor and don't impair correct invocation.
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 coverage is 100% and the schema already explains that models becomes ask_atlas_council's default persisted across sessions, that 'atlas:' is optional, and that omitting synthesizer keeps the built-in ladder. The description adds concrete examples and reiterates these semantics, but adds little beyond the schema. Baseline 3 applies.
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 is specific: it 'Save[s] the user's chosen Atlas Cloud council (and optionally its adjudicator) so it sticks across sessions', clearly identifying the resource (Atlas council config) and the operation (persist). It is unambiguously distinct from sibling tools like configure_openrouter_council or configure_ollama_council, and from ask_atlas_council which consults rather than configures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear when-to-use context: persist across sessions, override ASK_FABLE_ATLAS_COUNCIL / ASK_FABLE_ATLAS_SYNTHESIZER defaults. It also gives a concrete precondition—'Confirm the selection with the user first — call list_atlas_models to ground it in the live catalog.' It lacks explicit 'when not to use' exclusions or named alternatives, relying on the tool name for sibling routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and succeeds. It reveals the side effect of writing ask_fable's config file, persistence across sessions, overrides of environment defaults, the fact that changes apply on the next call, and the behavioral difference between 'full' and 'safe' trace modes. It also discloses that stream_reasoning goes to the server console rather than the tool result.
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 definition is information-dense and front-loaded with the core action in the first phrase. Each clause adds useful detail, but the opening sentence is long and packs multiple ideas (persistence, config file override, no restart, next-call timing) into one parenthetical-heavy statement. Still, nothing is wasted.
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 config-mutation tool with no annotations and no output schema, the description is remarkably complete. It explains persistence, override behavior, timing, both modes for trace_mode, the effect of stream_reasoning, and explicitly states the return value (effective settings and config path). An agent has enough to use it correctly.
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 coverage is 100%, so the baseline is 3. The description repeats and slightly expands on the schema's parameter descriptions (e.g., 'full' records redacted reasoning, 'safe' withholds content), but does not add substantially new semantic meaning beyond what the input schema already states.
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 starts with a specific verb+resource: 'Toggle reasoning-trace capture at runtime', which clearly states the action and target. It clarifies what the tool is for, but does not explicitly contrast itself with sibling tools like trace_get or trace_list, so it misses the top bar for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is a runtime toggle that persists, overrides env defaults, requires no ~/.claude.json edit or restart, and applies on the next call. It also says 'Pass either or both' to guide invocation. It does not explicitly state when to prefer this over read-only trace tools, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explicitly states the destructive action and that the tool returns whether a row was removed, which is useful. However, it does not mention permanence, irreversibility, or any potential side effects on related stored contexts or packs.
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?
Two sentences with no redundancy; the core action, the usage rationale, and the return behavior are all covered. The parenthetical is compact and earns its place.
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 single-parameter deletion tool with no output schema, the description covers the action, the reason to use it, the key parameter, and the return value. Nothing essential is missing for an agent to call it correctly.
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%, so the parameter is already documented ('Key to delete'). The description adds little beyond restating that deletion happens by key, which is expected given the high baseline coverage.
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 states a specific verb ('Delete'), a resource ('a stored context'), and the means ('by key'), which fully identifies the operation. The parenthetical 'housekeeping once a blob is no longer needed' adds a clear purpose and helps distinguish it from sibling read/write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'housekeeping once a blob is no longer needed' gives a clear condition for when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the usage context is easy to infer from the deletion intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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: it discloses a durable config-file mutation ('writes a durable default on their behalf', 'survives restarts'). It stops short of mentioning whether existing defaults are overwritten/merged or what the tool returns, so it isn't a 5, but the persistence side effect is clearly communicated.
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?
Two sentences with no filler: the first states purpose and persistence mechanics, the second condenses parameters and the user-choice workflow. Every sentence earns its place and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description covers the workflow (list first, let user pick), the parameters, and the side effect. Minor gaps remain — behavior on an empty call and overwrite/merge semantics — but they don't block correct invocation.
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 coverage is 100%, so the schema already documents both parameters with examples and prerequisites. The description adds the 'and/or' optionality and calls synthesizer the 'adjudicator', which slightly clarifies relationship but doesn't add material meaning beyond the schema.
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?
States a specific verb ('Persist') and resource ('default panel for ask_openrouter_council ... to the server's config file') with a stated outcome ('survives restarts'). Distinguishes from configure_ollama_council and configure_atlas_council by explicitly referencing ask_openrouter_council and naming the prerequisite list_openrouter_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit pre-step ('Call list_openrouter_models first') and a clear decision rule ('should reflect their choice, not yours'). It also implicitly contrasts with hand-editing an env var. It doesn't explicitly name alternative configure_* tools, but the OpenRouter-specific resource makes the intended target clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it rises to the task. It discloses the billing cost (N billed calls plus synthesis), parallel fan-out, the adjudicator default ladder ('the local `codex` CLI when installed, else OpenRouter-hosted GPT-5.6 Sol, else Fable'), the models omission fallback (configured set or 3 featured catalog models), and the Grok/Kimi reroute to local CLIs. This is substantive behavioral context well beyond what the schema alone provides.
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 core action is front-loaded in the first sentence and subsequent sentences efficiently add cost, default, fallback, and routing context without fluff. However, the synthesizer ladder and `models` omission behavior are repeated nearly verbatim from the schema, so a couple of sententes are slightly redundant. Overall it is dense and well-organized, but not every sentence strictly earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-param tool with no output schema and no annotations, the description covers purpose, cost, defaults, fallbacks, and configuration entry points. It references the fan-out/synthesis contract and `consensus` signal indirectly through `ask_council` rather than defining the return format, and it does not explain failure behavior when OpenRouter is not configured or when no models resolve. These are modest gaps for a tool of this complexity, so a 4 is appropriate.
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% with already-rich parameter text, so the baseline is 3. The description mostly restates schema content for `models` and `synthesizer` ('omit it to use the configured set...', 'adjudicator defaults GPT-first...'), adding little parameter-level meaning beyond the schema. The genuinely new details (cross-lab diversity rationale, Grok/Kimi reroute) are behavioral rather than parameter-semantic, so the description does not raise the score above baseline.
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: 'Ask SEVERAL OpenRouter models the same question in parallel, then have an adjudicator reconcile their answers into one.' It clearly differentiates this tool from the sibling `ask_council` by naming it ('Same fan-out/synthesis contract and `consensus` signal as `ask_council`') and from single-model `ask_openrouter` by emphasizing cross-lab diversity on a single API key. The purpose is unambiguous and distinct from the large sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use-case context and a cost-based gate: 'COST: this is N billed calls plus a synthesis — reserve it for a contentious, hard-to-reverse decision, exactly as with `ask_council`.' It also names the configuration alternative (`configure_openrouter_council`) and explains the fallback behavior when `models` is omitted. However, it does not explicitly state when NOT to use it (e.g., 'prefer `ask_openrouter` for a single quick answer'), so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 does well by disclosing that the store is shared server-wide, reusing a key overwrites the previous value, and the optional description surfaces in context_list. It does not cover retention limits or what the tool returns on success, but the key side effects are transparent.
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 front-loaded with the core action and uses its four sentences efficiently; every sentence adds useful operational context. The motivational 're-paste tax' phrase is slightly embellished, and 'paste it ONCE' is repeated in spirit later, but the overall structure remains tight and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter write operation with full schema coverage and no output schema, the description covers the key operational facts: shared store, overwrite behavior, usage with ask, and visibility in context_list. It does not specify return values or error behavior, but those are not critical for correctly invoking this tool.
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%, so the baseline is 3, but the description adds meaningful guidance beyond the schema: it gives key-naming conventions, reinforces the overwrite semantics, explains how value is consumed via context_ref, and clarifies that description is used for display in context_list. This elevates it above the baseline.
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 uses a specific verb ('Store') with a clear resource ('a chunk of context') and concrete examples (code, file contents, stack trace, design notes). It distinguishes this write tool from siblings by referencing context_read and context_ref, so an agent can tell at a glance that this is the write-side counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: store context once and reuse it via context_ref on ask instead of re-pasting code. It also mentions that sibling agents can context_read what was written, which helps clarify the relationship to related tools. However, it does not state explicit exclusions or when to prefer context_delete/context_pack.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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. It discloses that the tool performs two actions—optionally dumping the transcript to a file and clearing the session—and communicates the side effect on subsequent `ask` calls. This is sufficient transparency for a destructive operation, though it does not mention irreversibility or any return value.
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 a single, well-structured sentence where the core action and its consequence are front-loaded. Every phrase earns its place: the optional file dump, the clear action, and the resulting fresh topic all fit naturally without redundancy.
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 simple, parameterless-required destructive tool with fully described parameters in the schema, the description is complete enough for correct invocation. It explains the tool's purpose, effect, and the optional save behavior; no output schema is expected for such a side-effect-oriented operation, and the context signals indicate no hidden complexity.
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?
The top-level description adds no parameter details beyond the input schema, and every parameter in the schema already has a clear, semantically rich description, including defaults and the model namespacing behavior. With 100% schema coverage, the description need not compensate, so the baseline score of 3 is appropriate.
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 states a specific verb-resource pair ('dump and clear a Fable conversation session') and explicitly explains the intended effect ('so the next `ask` on that key starts a fresh topic'). This clearly distinguishes it from sibling tools like `session_list` or `session_peek`, which inspect rather than mutate, and `context_delete`, which targets context entries rather than conversation sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: before the next `ask` on a session key when you want a fresh topic. It does not explicitly name alternatives or list exclusion criteria, but the purpose and trigger condition are stated without ambiguity, so an agent can infer the appropriate usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: single-turn, local grok CLI, grok-4.6 by default, hermetic execution with tools disabled, use of the grok login session, and the binary_missing failure mode. It also explains the tool's scope limitations, which is valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-rich, but it is somewhat run-on and contains redundancy: 'single-turn' appears twice, and various parentheticals are stacked. The final sentence about refused domains trails off, making the structure feel less polished than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers the key operational context: prerequisites, failure behavior, execution mode, and scope. The only minor gap is the lack of detail about the response format, and the incomplete final sentence leaves the refusal list slightly ambiguous.
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%, so the baseline is 3. The description adds some extra meaning by saying 'put the code it needs in context' and characterizing the question as a 'specific software/engineering question,' but it does not substantially elaborate on the parameters beyond what the schema already provides.
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 clearly states this tool asks xAI's Grok model to reason about software/engineering work, listing concrete topics like code structure, data flow, and architecture. It also explicitly distinguishes itself from ask_atlas and from Fable by saying it is 'on its own, independent of Fable'.
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 gives an explicit preference rule: 'PREFER THIS over ask_atlas with xai/grok-* whenever the grok binary is installed.' It also states what kinds of questions are fine (broad engineering questions) and what is not (offensive security, non-software knowledge), and notes the prerequisite that the grok CLI must be installed and logged in.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses several behaviors: it synthesizes one answer while returning raw answers under `sources`, calls optional `quorum`/`degraded` result fields, uses a local signed-in `ollama` daemon by default (no API key needed), and notes that model configuration falls back to ASK_FABLE_OLLAMA_COUNCIL. Minor gaps remain (e.g., no mention of error handling if no models are available or daemon is down), but the description is unusually transparent for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-rich, but it is a long, single run-on block with many stacked clauses and parenthetical asides (e.g., the broad scope/refusals list is packed into the tail). The most critical routing information ('DIRECTIONAL', 'counterpart to ask_council', 'default to ask') is front-loaded, which is good, but the overall structure would benefit from splitting scope/refusal rules from invocation details. It earns a 3 — content is all relevant, but readability suffers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 5 parameters and no output schema, the description covers invocation modes (explicit model list vs. server default), auth expectations (local signed-in daemon, no API key needed), scope rules (what is in/out of scope), and output behavior (synthesized answer plus `sources`). It lacks a note on the shape of the synthesized answer beyond 'one answer' and doesn't explain what happens if models are invalid or unreachable, but the high schema coverage and rich routing details make it largely complete for an agent to decide whether and how to call it.
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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by giving concrete example model ids, clarifying the optional 'ollama:' prefix, and explicitly stating the effect of omitting `models` (server-configured set). It also explains the `sources` relationship to the `question` parameter's output. This extra context justifies a 4 rather than a baseline 3.
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 verb+resource ('Ask several Ollama Cloud models the same SOFTWARE/ENGINEERING question at once') and immediately differentiates itself from the sibling `ask_council` by stating it is the Ollama-only counterpart. It also clarifies scope (broad engineering questions, with explicit refusals), making the tool's identity unambiguous.
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?
Provides explicit when-to-use guidance: 'reserve it for a contentious or hard-to-reverse decision', 'not for routine questions (default to `ask`)', 'at most one council call per problem'. It also names both alternatives (`ask` and `ask_council`) and distinguishes when to choose each, which is exactly the routing help an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It explicitly states read-only, makes no model call, returns conversation bounded by retention, and never feeds back into an oracle's context.
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 longer than the minimum but every sentence earns its place: coordination context, use cases, optional filtering, read-only behavior, retention bound, and comparison to session_list. It is front-loaded with the core action and not redundant.
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 simple read-only tool with only two parameters and no output schema, the description fully covers what is returned (ordered full turn history), the retention bound, and the absence of side effects. An agent has enough information to call it safely and understand the result.
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 coverage is 100% and the description's mention of 'Optionally scope to one agent_id' mostly restates the schema's own parameter description. It adds no new format, constraint, or semantic detail beyond what the schema already provides.
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?
States a specific verb and resource: read the full turn history for one session, with scope 'across instances.' It also distinguishes itself from session_list by calling out visibility-only behavior, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit use cases: understand what an agent learned before joining work, or recover a finding another instance produced. It clearly says it is visibility-only and never feeds back into an oracle's context, though it does not explicitly contrast with session_list or context_read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it declares read-only semantics, no model call, no caching, and per-view behavior nuances (provider view sees council members individually and circuit_open sheds). Minor omissions like empty-window behavior and bucket ordering prevent a 5, but the safety and side-effect profile is fully disclosed.
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?
Five dense sentences, front-loaded with the core purpose before any detail. Every clause earns its place: scope, bucketing/aggregates, filters, council-record extras, example queries, and the no-call/no-cache guarantee — no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by naming the returned metrics (calls/allowed/refused/errors, avg and p95 latency, error_rate, totals, plus quorum/consensus/synth_fallback), which is the critical missing piece. It covers defaults, filters, and view semantics; the only gaps are the exact JSON response shape and bucket limits/ordering, which are minor for a read-only stats tool.
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% with genuinely descriptive parameter docs, so the baseline is 3. The description adds interpretive value beyond the schema by explaining that model/session filters 'narrow to one backend or workflow' and by listing the metrics produced per bucket, which gives the agent a mental model of what bucketing by each key yields.
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 first clause states a specific verb and resource: "Read-only usage/health stats aggregated from the ask_fable audit log." It further distinguishes itself from the large ask_*/list_*/trace_* sibling family by framing itself as the performance-monitoring tool ('see how the tools are performing without spelunking JSONL'), which no sibling claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Concrete example questions ('is GLM erroring a lot today?', 'how slow are councils this week?') tell an agent exactly what kinds of queries route here, and 'makes no model call and is never cached' clarifies when it's safe/appropriate to invoke. It does not explicitly name exclusions or alternatives (e.g., session_stats for per-session detail), so it stops short of full when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses several non-obvious traits: operation is single-turn, reached via a local signed-in ollama daemon with no API key, model default behavior, and refusal categories. This goes well beyond the schema, though it stops short of describing output format or side effects, so a 4 is appropriate.
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 lengthy but each clause earns its place: scope, model selection, transport, turn semantics, acceptable topics, refusals, and an alternative. It is front-loaded with the primary purpose. Slight verbosity in the refusal list prevents a 5, but the structure is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a Q&A tool with no output schema, the description covers nearly everything an agent needs: allowed questions, refused categories, context parameter usage, model selection, and the council alternative. It doesn't describe the response shape or error behavior, but those are not critical for invoking a single-turn question tool. The large sibling set is handled by explicit differentiation from ask_council.
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 description coverage is 100%, so the baseline is 3. The description adds real value by giving concrete model id examples, explaining when to use `context` ('add a snippet or file path... when the question is about existing code'), and clarifying the default behavior when `model` is omitted. This lifts it above the baseline.
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: 'Ask a single Ollama Cloud model — on its own — to reason about the SOFTWARE/ENGINEERING work.' It clearly enumerates the topics (code structure, data/control flow, architecture, design trade-offs) and contrasts with ask_council, so an agent can distinguish it from siblings without inspecting the 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?
The description provides explicit when-to-use guidance: broad conceptual engineering questions are fine, while offensive-security and non-software domain questions are refused. It also tells the agent to add context for existing-code questions and points to an alternative tool ('Use ask_council to mix Ollama models with Fable'), covering both positive and negative cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so admirably. It states the side effect (writes to config file), precedence behavior (overrides ASK_FABLE_OLLAMA_* env defaults), persistence scope (across sessions), input normalization ('ollama:' prefix optional, bare names normalized to ':cloud'), and the return value (saved config and file path). This fully informs an agent of the persistent-mutation nature of the call.
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 dense but every sentence earns its place: purpose, parameter details, normalization rule, optional parameter, user-confirmation workflow, and return value. It front-loads the primary purpose before diving into specifics, and the structure follows a logical flow from what it does to how to use it to what it returns.
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 config-persistence tool with no annotations and no output schema, the description covers everything an agent needs: preconditions (confirm with user, call list_ollama_models), side effects (config file write, env override), parameter semantics, normalization behavior, and return value (config file path). No critical operational detail is left implicit.
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%, so the baseline is 3. The description's parameter explanations largely restate the schema text (list of cloud model ids, normalization, default_model for ask_ollama). It does add a concrete example array and ties the parameters to downstream tool behavior, but it doesn't significantly extend semantic understanding beyond what the schema already provides.
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, actionable purpose: 'Save the user's chosen Ollama Cloud council so it sticks across sessions.' It names the exact resource (Ollama Cloud council), the mechanism (written to ask_fable's config file), and the effect (persists, overrides env defaults). It also clearly distinguishes itself from sibling configure_atlas_council and configure_openrouter_council by scoping to Ollama Cloud while referencing the dependent ask_ollama_council and ask_ollama tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit operational guidance: confirm with the user first and call list_ollama_models to ground the selection in available models. It also explains how the parameters map to downstream tools (ask_ollama_council, full tier, ask_ollama). It stops short of explicitly stating when not to use this tool versus the config alternatives, but the Ollama Cloud naming and list_ollama_models call make the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It clearly states 'Read-only', explains that it fetches the live ollama.com catalog, notes that local models are certain to run, and describes outputs as daemon-ready ids. This goes well beyond a generic 'list' statement and covers the main behavioral and safety expectations.
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?
Three dense sentences front-load the purpose, then describe outputs, then give the workflow. The illustrative list of model names and the rationale 'instead of guessing' add useful context without padding, and the 'Read-only' note is efficiently placed.
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 one-optional-parameter, read-only tool with no output schema, this description is complete enough: it covers when to use it, what it returns, why it matters, and the follow-up action. An agent can correctly invoke it and interpret the result categories without additional guessing.
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 coverage is 100%, and the input schema already documents the refresh parameter's true/false behavior in detail. The description adds no meaningful parameter semantics beyond mentioning live versus currently-configured data, so the baseline of 3 applies.
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?
States a specific action ('List') and resource ('Ollama Cloud models available to put in the council'), and further specifies that it returns the live catalog, locally pulled models, and the currently configured council. The 'Ollama' and 'council' specifics clearly distinguish it from sibling listers like list_openrouter_models and list_atlas_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('first time an Ollama council is wanted' or 'user asks to configure ask_fable') and a concrete workflow: call, show options, ask, then persist with configure_ollama_council. It does not explicitly name alternative list_*_model tools or state when not to use them, but the Ollama-specific condition makes routing fairly unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and meets it: it discloses that the endpoint needs no API key and costs nothing, that ranking reads the catalog's own live fields so newly released models rank correctly, that cheap/fast/high-volume keywords flip tier preference, and that the tool must surface a price-annotated shortlist rather than silently pick an expensive model. This is far richer behavioral disclosure than the schema alone provides.
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?
Five dense sentences, all earning their place, with the core purpose front-loaded before the ranking and UX guidance. It is longer than minimal but every clause adds operational value; nothing reads as filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers a lot: returned fields, authentication/cost, ranking mechanics, keyword behavior, and user-presentation policy. The remaining gaps are minor — the exact response shape and failure behavior for the network fetch are left implicit — but nothing an agent needs to call it safely or correctly is missing.
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%, setting a baseline of 3. The description adds real meaning beyond the schema for the task parameter — explaining that ranking uses the catalog's own data and that keyword mentions of cheap/fast/high-volume redirect the ranking — and for interactive via the 'show the user and let them choose' guardrail. limit and refresh gain little beyond their schema text, so the bonus is partial.
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 names a specific verb and resource — 'List the live OpenRouter catalog' — and enumerates exactly what is included (~400 models, price per million tokens, context window, reasoning efforts). It is instantly distinguishable from list_ollama_models and list_atlas_models by naming the OpenRouter source, and from ask_openrouter by the explicit 'call it before' instruction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to invoke it: 'call it before ask_openrouter rather than guessing a model id,' naming the sibling and the rationale. It also explains when the optional task-ranking path applies and how task phrasing alters results. It does not explicitly state when-not-to-use cases, but the primary alternative is named and the ordering is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of safety disclosure, and it does this well: it states 'Read-only, makes no model call' and clarifies that it is 'Visibility-only — never affects oracle answers; oracles only see what a calling agent explicitly passes'. It also defines the internal staleness heuristic (~5 min heartbeat threshold) that shapes the `active_only` default. Minor deduction: it does not describe the exact output list ordering or whether entries are capped by `limit` before or after filtering, but those are less critical for selection and invocation.
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 dense but purposeful; every sentence adds behavioral or selection-relevant information. The opening word 'COORDINATION' acts as a category cue and front-loads the purpose. Minor deduction: the last sentence about visibility is slightly repetitive with the earlier 'Read-only, makes no model call' claim, so it could be tightened. Overall it is well under the length where an agent's attention starts to degrade.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter list tool with no output schema, the description is nearly complete: it names the dashboard's purpose, what fields appear in entries, the defaults, the override flags, the staleness meaning, and the non-interference guarantee. The main gap is a lack of detail about pagination or truncation behavior (does `limit` default to 50 and cap at 200 in a simple head or does it page?), and it does not mention whether the ordering is by heartbeat recency. Still, an agent could confidently select and invoke it without further clarification.
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 description coverage is 67%: `active_only` and `all_projects` already have descriptions in the schema, while `limit` has only its default/min/max. The tool description adds the crucial semantics for the two booleans — e.g., that `active_only: false` yields 'retained history' and that `all_projects: true` means 'whole machine' — and it explains the default hint 'so the dashboard shows live work'. This is strong beyond-schema value. Deduct one point because the description does not add detail about `limit`'s effect beyond the schema's numeric bounds.
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 label ('COORDINATION — the operator dashboard') and states the specific verb+resource: lists ask_fable sessions across instances. It details exactly what each entry contains (session key, agent_id, latest question, oracle, status, heartbeat age, turn count), which strongly distinguishes it from siblings like session_stats, session_peek, and reset_session. An agent can immediately tell this is a read-only monitoring tool rather than a per-session query or mutation.
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 gives explicit defaults ('THIS project only', `active_only: true`) and explains when to flip them: pass `active_only: false` for retained history and `all_projects: true` for the whole machine. It also gives a concrete use case ('avoid duplicate work or watch the live fleet'), which helps an agent decide between this and session_peek or session_stats. This fully satisfies when-to-use guidance within the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and largely succeeds: it reveals the single-turn nature, the ASK_FABLE_DEEPSEEK_API_KEY prerequisite with its not_configured failure mode, refusal categories, and in-scope domains. It stops short of describing the response payload on success or refusal, but the key behavioral gotchas are disclosed.
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?
Though longer than the calibration ideal, every sentence earns its place: model identity, scope, cost preference, config prerequisite, refusal policy, and sibling routing. It is front-loaded with the core purpose and contains no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, no-output-schema, no-annotation tool, this description is nearly complete: what to ask, how to pass context, config requirements, refusals, and routing to siblings. The only minor gap is expected response behavior on refusal or misconfiguration, but for a simple ask tool the primary answer shape is self-evident.
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%, so the baseline is 3, and the description adds genuine value by clarifying model identity for the question parameter and instructing when to populate context ('add a snippet or file path in context when the question is about existing code'). context_ref is fully served by the schema, so no further elaboration is needed.
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 states a specific verb+resource: 'Ask the DeepSeek model (deepseek-v4-pro...)' and a clear engineering scope — code structure, flow, architecture, design trade-offs. It explicitly distinguishes itself from Fable and names the model, making it unmistakable against the large ask_* sibling family.
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?
Provides explicit when-to-use guidance ('Cheap direct API — prefer it... for a quick independent opinion'), when-not-to-use conditions (offensive-security and non-software domains are refused), and named alternatives ('Use ask for Fable, ask_m3 for MiniMax, ask_glm for GLM, or ask_council...'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses read-only behavior, no auth needed, free/no tokens charged, native popup side effects, a structured fallback, and the no-network refresh=false behavior. This is strong behavioral disclosure for a tool with zero annotation support.
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 and dense, but almost every clause earns its place because there is no output schema and no annotations to fall back on. It front-loads the core purpose and workflow before the return-format detail. Stylistically it is a bit overloaded with all-caps emphasis, which keeps it from a 5.
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 no output schema and no annotations, this description is exceptionally complete: it covers return payload shape, cost/auth implications, task ranking, interactive behavior, fallback handling, and the next tool to call. Nothing critical for an agent to use it correctly is missing.
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%, so the baseline is 3. The description adds extra practical meaning by explaining that `task` drives ranking, that native elicitation is tied to `interactive`, and that `refresh=false` means no network. It doesn't radically expand on the schema, but it does connect parameters to real usage scenarios.
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+resource pair ('RECOMMEND AND PICK an Atlas Cloud text model') and clearly explains the ranking, picker, and catalog-listing behaviors. It differentiates from siblings by scoping to Atlas and explicitly pointing to ask_atlas for the follow-up accept action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'REACH FOR THIS the first time an Atlas model is wanted' and explains when a task should be passed. It also routes the follow-up to ask_atlas, but it does not explicitly mention exclusions for the sibling Ollama/OpenRouter model-list tools, so the when-not-to-use guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses single-turn behavior, the backend model and fallback behavior (GLM-5.2 via Z.ai when the key is set, otherwise Atlas-hosted GLM-5.3), not_configured reporting, and the refusal policy for offensive-security and non-software domains. This is strong behavioral disclosure beyond what a name or schema alone would convey.
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 core purpose is front-loaded and the description is well organized, but the backend/endpoint sentence is more implementation detail than an agent strictly needs for selection or invocation. Still, every sentence serves a real purpose given the configuration, refusal, and alternative-routing details it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description still provides the essential information needed to call the tool correctly: what to ask, how to provide context, what is refused, and which sibling tools to use instead. It leaves the exact return shape implicit and does not explicitly distinguish ask_glm from every model-specific sibling, but these are minor gaps.
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 description coverage is 100%, so the baseline is 3. The description adds value by instructing users to include a snippet or file path in context for questions about existing code and by clarifying that broad/conceptual engineering questions are acceptable. It does not add much on context_ref beyond what the schema already documents.
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 starts with a specific verb-resource-scope statement: 'Ask the GLM model — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing.' It enumerates concrete topics such as code structure, data/control flow, architecture, and design trade-offs. It also distinguishes itself from siblings by explicitly saying 'Use ask for Fable, ask_m3 for MiniMax, or ask_council.'
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 when the tool is appropriate: software/engineering reasoning, broad conceptual questions, and existing-code questions with a snippet or file path in context. It names alternatives directly — ask for Fable, ask_m3 for MiniMax, ask_council for synthesized multi-model answers — and establishes exclusions such as offensive-security asks and non-software domain knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden — and it delivers: single-turn mode, sandboxed pure-text reasoning with no filesystem/tool access, the 131k-byte argv cap with refusal behavior, prerequisite `kimi` CLI + `kimi login` with error states, and explicit refusal boundaries (offensive security, biology/medicine refused; neuroscience, cognitive science, AI/ML, CS in-scope). This is unusually thorough behavioral disclosure.
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: purpose first, then routing preference, then caveats, sandbox, prerequisites, refusals, alternatives — each sentence earns its place given the zero-annotation environment. However, the dense em-dash and parenthetical asides make parsing harder than necessary, so it falls just short of top marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must be self-sufficient, and it covers nearly everything: purpose, alternatives, prerequisites, error states, size limits, refusal boundaries, and cost implications. It does not explicitly describe the return value format, though 'sandboxed to pure text reasoning' strongly implies a text answer — a minor gap for an otherwise complete definition.
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%, so the baseline is 3. The description adds meaning beyond the schema by explaining why `context` matters ('the model has NO filesystem or tool access, so put the real code in `context`') and by tying the `question` parameter to the argv size cap. This goes one step beyond the schema's own documentation.
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 names a specific verb ('Ask'), a specific resource (Moonshot's Kimi model kimi-code/k3 via the local `kimi` CLI), and the scope (SOFTWARE/ENGINEERING work: code structure, functionality, data/control flow, architecture). It distinguises from sibling tools by adding 'on its own, independent of Fable' and explicitly contrasts itself with `ask_atlas`, `ask`, `ask_m3`, and `ask_council'.
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: 'PREFER THIS over `ask_atlas`... whenever the `kimi` binary is installed', with the billing rationale. Gives when-not-to-use: prompts over the 131k-byte argv cap should be routed to `ask_atlas`. Also names the siblings for other purposes: 'Use `ask` for Fable, `ask_m3` for MiniMax, or `ask_council` to ask several'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does so well by stating the tool is single-turn, independent of Fable, and has specific refusal categories. It also clarifies in-scope domains (neuroscience, cognitive science, AI/ML, CS). Minor gaps remain, such as whether the model has access to conversation history, but the description provides meaningful behavioral context.
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 dense but efficient, packing purpose, scope, exclusions, limitations, and alternatives into a few sentences. Each sentence earns its place, and the most important information—what the tool does—is front-loaded.
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 model-ask tool with three parameters and a fully described schema, the description covers the essential contextual information: the model's identity and scope, refusals, single-turn behavior, how to provide context, and how to choose an alternative tool. Nothing critical is missing for an agent to invoke it correctly.
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%, so the baseline is 3. The description adds value by explaining when and how to use the `context` parameter: add a snippet or file path when the question is about existing code. It does not explicitly discuss `context_ref`, but the schema already documents it, so the description's additional guidance lifts this slightly above baseline.
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 clearly identifies the resource (MiniMax-M3 model) and the action (ask it to reason about software/engineering work), listing concrete topics like code structure, data flow, routing, and design trade-offs. It also distinguishes this tool from siblings by stating it is 'independent of Fable' and that `ask` is for Fable and `ask_council` is for both.
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 gives explicit when-to-use guidance: use this tool for broad, conceptual engineering questions, and add context when asking about existing code. It also states exclusions (offensive security, non-software domains like biology/medicine) and names alternatives: `ask` for Fable and `ask_council` for both.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses the result shape (sidecar, followup, context_exhausted), the session/reset model, per-tool session namespacing, the model's lack of tools and file access, the refusal scope, and the tool's role in multi-model modes. This is substantial behavioral context beyond the schema.
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 well-organized into clear sections (purpose, when-to-use, sessions, limitations, scope, multi-model role). Almost every sentence earns its place, though 'same as ask' is repeated a couple times and the wall of text could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool, the description covers most invocation-relevant context: when to use it, model limitations, session behavior, refusals, and multi-model integration. However, with no output schema, the result-shape terms like `sidecar` and `context_exhausted` are named but not explained, which is a minor completeness gap.
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%, so the baseline is 3. The description adds value beyond the schema by advising to paste real code into `context` or use `context_ref`, explaining that sessions are namespaced per tool, and noting arguments are identical to `ask`. This helps the agent use parameters more effectively.
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 states a precise purpose: the same multi-turn reasoning as `ask` but on Claude Opus 5, with identical arguments and result shape. It clearly differentiates the tool from its sibling `ask` by model choice and explicitly names that sibling.
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 explicitly says 'Reach for it exactly where you'd reach for ask' and provides a 'WHICH ONE' section comparing Opus 5 vs Fable on price, speed, and consequence. It also suggests running both as a cross-check, giving clear routing guidance relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 fulfills it well. It explicitly states the operation is read-only and discloses that full values are never returned, which is a meaningful behavioral guarantee that prevents an agent from expecting content leaks.
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?
Two sentences with no wasted words. The action and resource are front-loaded, the return format is compactly summarized, the safety constraint is explicit, and the usage scenario is included in a natural way.
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 no-parameter, read-only listing tool, this description covers naming, output scope, constraints, and use case. An agent has everything needed to decide when to call it and what to expect.
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?
The tool has zero parameters and the schema is fully covered, so there is nothing for the description to add. Per the baseline for zero-parameter tools, this is appropriate.
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 names a specific verb ('List'), a specific resource ('shared context store'), and enumerates exactly what is returned (key, size, age, description). It also explicitly excludes full values, which distinguishes it from context_read. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: discover available context before re-pasting and reference via `context_ref`. It does not explicitly state when to use context_read instead, but the statement 'never the full value' gives a strong implicit contrast with the read sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does so thoroughly. It discloses the security boundary ('reads never escape that root'), the hard refusal of `.git/`/`.env*`, the `not_configured` failure mode, the `skipped` reporting mechanism with reasons and `complete:false`, the no-silent-truncation guarantee, and the untouched-store guarantee when nothing can be packed. This is model-friendly and trust-building.
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 every sentence carries distinct information: the core value proposition, the usage pattern, the spec syntax, the safety boundary, the configuration prerequisite, and failure semantics. It is front-loaded with 'Point, don't paste' and flows logically from motivation to mechanics to edge cases. No filler or redundancy.
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 no annotations and no output schema, this description is complete. It tells the agent what inputs are expected, how to form paths, what happens on configuration failure, how partial failures are surfaced, and how the result is consumed by sibling tools. The only minor omission is the exact success return shape, but the 'skipped/complete' references make the contract understandable.
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%, so the baseline is 3; the description raises it by adding meaning beyond the schema. It specifies the default character budget (~24000), the project-root configuration requirement (config or env var), and the semantics of spec formats. These details help an agent pick good values and anticipate failure without needing extra research.
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 memorable, specific framing — 'Point, don't paste' — and then states the exact function: name files and optional line ranges, have the server read them, apply a character budget, and store the bundle under `key` on the context bus. It clearly distinguishes this from the ask/council siblings by explaining that the context_ref from this tool is then passed to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use the tool: instead of hand-pasting code when the repo isn't visible to the model, with the local server reading files. It also explains the follow-up flow — pass `context_ref='<key>'` on `ask`/councils. It does not explicitly contrast with context_write/context_read siblings, but the 'don't paste' instruction strongly implies the file-based use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the return payload (stored value, size, age, description) and the not_found behavior for missing keys, which is strong transparency for a simple read operation.
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?
Three sentences with no filler. The core action, return value, error case, and intended use are all packed in efficiently, and the most important information is front-loaded.
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 single-parameter, no-output-schema read tool, this description is complete. It covers what it reads, how to reference it, what is returned, what happens on failure, and why an agent would use it.
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?
The schema explains the key parameter minimally, but the description adds meaningful context: the key refers to something saved with context_write, and reads of unset keys return not_found. This adds value beyond the schema even though schema coverage is already 100%.
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?
States a specific verb and resource: it reads back context by key, referencing context_write as the complementary write operation. It also clarifies the difference from pure key listing by saying it returns the stored value plus metadata, so an agent can distinguish it from context_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it: to inspect a shared blob or consume context another agent wrote. It does not name alternatives like context_list or context_delete for exclusion, but the intended use cases are clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosure burden and delivers: the adjudicator default ladder (local codex CLI → atlas:openai/gpt-5.6-sol → Fable), a fallback disclosure ('Falls back to Fable when the pick is unavailable or fails'), result-structure hints (`sources`, `synthesis`, `quorum`/`degraded`), authentication requirements, and the grok-to-local-CLI rerouting. It even flags the refusal scope, so an agent can predict failures before invoking.
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 dense but nearly every clause adds information — routing, defaults, auth, failover, scope. It front-loads the pivotal usage constraint ('reserve it for... not for routine questions'), though it packs a lot into run-on parentheticals that would be easier to parse as shorter sentences.
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 6-parameter, annotation-free tool with no output schema, the description covers the full decision-relevant surface: when to choose it, how invocation behaves (synthesis, sources, fallback), how to set models, what auth is needed, and what is refused. It also names the sibling for mixed-provider councils, giving an agent the complete routing picture. The only minor gap is the meaning of `quorum`/`degraded`, but checking them is already flagged.
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%, so baseline is 3. The description adds genuine value beyond the schema: a concrete example model-id list, the default composition ('3 featured catalog models, one per provider'), the optional 'atlas:' prefix, and the practical note that synthesizer can override with 'any council token'. These enrich the models and synthesizer semantics rather than merely repeating the schema.
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 names a specific verb-resource pair: 'Ask several Atlas Cloud models the same SOFTWARE/ENGINEERING question at once, then get back one answer the adjudicator synthesizes.' It immediately distinguishes itself from its closest sibling ('the Atlas-only counterpart to ask_council') and states the exact question scope, including what is refused.
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 gives explicit when-to-use guidance ('reserve it for a contentious or hard-to-reverse decision'), an explicit when-not-to ('not for routine questions (default to ask)'), a hard constraint ('at most one council call per problem'), and names the routing alternative for mixed-provider councils ('Use ask_council instead to mix Atlas models with Fable/MiniMax/GLM/DeepSeek'). This is textbook conditional routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses hermetic and read-only operation ('can't see or touch your repo'), single-turn behavior, the binary_missing error condition, and refusal boundaries for offensive-security and non-software domains. This is exemplary transparency for a tool with zero annotations.
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 the core purpose and every sentence adds functional or routing information. It loses a point due to slight redundancy: `ask_council` appears twice in the alternatives list, and the final enumeration of siblings is lengthy relative to what the sibling list already provides.
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 complex tool with no output schema and no annotations, the description covers purpose, prerequisites, error mode, behavioral limits, scope restrictions, and context usage. Nothing an agent needs to decide whether to call this tool or how to pass the required parameters is missing. The only absence is an explicit return format, but for an ask-style tool that is sufficiently implied.
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 description coverage is 100%, so the baseline is 3. The description adds usage meaning beyond the schema by explaining the `context` parameter's purpose ('put the code it needs in `context`') and clarifying what kinds of `question` are acceptable ('Broad and conceptual engineering questions... are fine'). It doesn't redundantly repeat schema text, and `context_ref` is already well documented in the schema.
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 states a specific verb and resource: 'Ask OpenAI's model (GPT-5.6 Sol, via the local codex CLI...)' and enumerates the scope: reasoning about code structure, data/control flow, architecture, and design trade-offs. It distinguishes itself from siblings by explicitly naming alternates at the end, so an agent can tell it apart.
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 gives explicit when-to-use guidance: 'add a snippet or file path in `context` when the question is about existing code' and routes to alternatives: 'Use `ask` for Fable's built-in ChatGPT, `ask_chain`/`ask_debate` for multi-step reasoning, `ask_council` for broader advisor groups...' It also states prerequisites: 'Requires the `codex` CLI installed and logged in on the server.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does so thoroughly. It discloses the deterministic resolution values ('conceded', 'converged', 'adjudicated', 'stalemate'), the confidence downgrade on stalemate, the cost of up to four sequential model calls, the degradation to a single-critic pass when opponent is unconfigured, and refusal scope for offensive security and non-software domains.
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 every clause earns its place given the tool's complexity. It is front-loaded with the directional/adversarial core and the sibling comparison before diving into parameters. It could be more scannable with bullet points, but the density of high-signal information justifies the length.
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 an 8-parameter tool with no output schema, the description is complete: it explains workflow, model role selection, defaults, aliases, outcome vocabulary, cost, fallback behavior, and allowed/refused domains. An agent has everything it needs to invoke ask_debate correctly and interpret its resolution, with no missing structural information.
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%, so the baseline is 3. The description adds genuine value over the schema: concrete model choices (proposer='fable', opponent='codex', adjudicator='opus'), alias resolution ('m3'=minimax, 'gpt'=codex, 'opus5'=opus), the strategic advice to keep the adjudicator off the debating pair, and the meaning of rounds. This goes beyond restating parameter types.
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, vivid verb phrase — 'pit two models AGAINST each other over a structured claims ledger, then have a fresh third model adjudicate' — and names the exact workflow (propose, refute, revise, rule). It explicitly contrasts with ask_council and ask_chain, so an agent can immediately tell this tool apart from its closest siblings.
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 precisely when to use it: 'Reserve it for a genuinely contentious, hard-to-reverse SOFTWARE decision' with examples like concurrency soundness or approach X vs Y, and when not to use it: 'not for questions with a clear answer.' It also names alternatives (ask_council, ask_chain) and warns this is the most expensive mode, to be used sparingly, plus scope refusals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and it delivers: single-turn semantics, the binary_missing failure mode when the agy CLI is unavailable, and explicit refusals for offensive-security and non-software domains. It even clarifies in-scope domains (neuroscience, cognitive science, AI/ML, CS) so the agent can distinguish refusals from valid questions.
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 front-loaded with purpose, then usage, then failure/refusal behavior, then sibling routing — no redundant filler. Each sentence contributes distinct decision-relevant information for an agent choosing and invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-turn LLM query tool with no output schema, the description covers needed dependencies, refusals, and scope, and the schema covers parameter semantics. The only minor gap is that it never names the response shape, but that is reasonably inferable and partially disclosed through the binary_missing error mention.
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?
The input schema already documents all three parameters at 100% coverage, including the context_ref key behavior. The tool description adds marginal value by advising to place a snippet or file path in context when a question references existing code and by emphasizing the question must be software/engineering-specific.
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 first clause names a specific verb ('Ask'), a specific model ('Gemini 3.1 Pro'), and the invocation path ('local agy CLI'), and narrows the subject to software/engineering work. It also distinguishes itself from Fable-bound siblings and from the other ask_* tools by listing the exact kinds of questions it handles.
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 explicitly states when to use the tool (broad/conceptual software engineering questions, brainstorming), when to include context (questions about existing code), and which alternatives to use instead (ask for Fable, ask_m3, ask_glm, ask_council). It also lists refusal categories, so an agent can avoid out-of-scope asks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It discloses that the tool is read-only, makes no model call, aggregates across all instances, defaults to a 24-hour window, supports full-history via window_s:0, and returns specific metrics. This is excellent behavioral disclosure.
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 dense but every sentence carries useful information: scope, sibling distinction, time window, returned fields, project scoping, example use cases, and safety. The 'COORDINATION' prefix is slightly unnecessary but not harmful.
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 read-only statistics tool with no output schema, the description covers parameters, semantics, return fields, default behavior, project/machine scope, and use cases. Nothing important for correct invocation is missing.
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%, so the baseline is 3. The description adds practical context by explaining what window_s:0 means, what all_projects:true does, and how defaults apply to project scope, going slightly beyond the schema field 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?
Description clearly states a specific verb and resource: aggregated oracle usage across ALL instances on the machine. It also explicitly contrasts with the sibling `stats` tool, so an agent can distinguish them immediately.
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?
Provides explicit when-to-use guidance with example questions like 'which agents are burning the most oracle calls?' and 'how is the fleet doing today?'. It also names the alternative `stats` and explains the scoping condition that selects one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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: it discloses single-turn behavior, API key requirements (ASK_FABLE_ATLAS_API_KEY or ATLASCLOUD_API_KEY), local-CLI auto-routing for Grok models, HTTP for others, free model-catalog calls, and refusal domains. It also states that broad conceptual engineering questions are fine while offensive-security and non-software domain asks are refused.
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 the length is largely justified by the tool's routing complexity, auth requirements, and sibling relationships. Core purpose is front-loaded and each sentence carries distinct operational information; however, the density and extended routing details make it slightly harder to scan quickly.
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?
Despite having no output schema and five parameters to contextualize, the description is operationally complete: it covers model selection flow, effort behavior, context usage, auth requirements, cross-tool token syntax, refusal policies, and single-turn semantics. An agent gets enough guidance to invoke the tool correctly and route around alternatives.
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 substantial meaning beyond the schema: it gives concrete model examples, explains the effort parameter's token-budget and reasoning_effort mapping, clarifies the default when model is omitted, and advises passing context for questions about existing code. This exceeds the baseline expected from schema-only documentation.
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, resource, and scope: 'Ask a single Atlas Cloud text model — on its own — to reason about the SOFTWARE/ENGINEERING work you're doing.' It also names the behavioral boundary that separates it from siblings like ask_council, ask_chain, and ask_debate ('single', 'on its own'), making the tool's identity clear.
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 gives explicit, actionable routing: 'REACH FOR THIS the first time an Atlas model is wanted: call list_atlas_models... then call ask_atlas', and it explicitly prefers ask_grok for Grok models when the local CLI exists. It also clarifies when to use sibling multi-model tools via dynamic atlas:<model> tokens, providing both positive and negative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses that the call bills the operator's OpenRouter credit per token, that the result reports real dollar cost, that the tool is guarded and single-turn, and how effort and default model selection behave.
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 densely informative; every sentence contributes purpose, workflow, cost, or redirection. It is front-loaded with the core function before diving into model selection and billing details, and there is no 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?
Despite having no output schema, the description covers return-cost reporting, billing, defaults, model selection prerequisites, and explicit alternatives among siblings. For a pay-per-token tool with many similar ask siblings, this is a complete operational picture.
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%, establishing a baseline of 3, but the description adds meaningful parameter context: model selection should come from the live catalog with pricing, effort adapts to the chosen model's supported reasoning levels, and context_ref pulls saved context by key. This goes beyond the schema's own 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?
States a specific verb and resource: 'Ask ONE model on OpenRouter', and clarifies it is a gateway to ~400 models from multiple labs. It explicitly differentiates from sibling ask tools by naming use cases: reaching models without a dedicated tool and comparing the same question across labs.
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?
Provides explicit when-to-use and when-not-to-use guidance: prefer dedicated tools like ask or ask_opus5 when one exists for the same model. It also gives a concrete workflow — call list_openrouter_models first, offer the ranked shortlist, then ask — and notes rerouting behavior for Grok and Kimi.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ask-fable MCP server](https://glama.ai/mcp/servers/baggybin/ask-fable/badges/card.svg)](https://glama.ai/mcp/servers/baggybin/ask-fable)

Score Badge

Copy to your README.md:

[![ask-fable MCP server](https://glama.ai/mcp/servers/baggybin/ask-fable/badges/score.svg)](https://glama.ai/mcp/servers/baggybin/ask-fable)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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