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

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

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

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

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context beyond annotations: stages run sequentially, each middle stage critiques prior draft, final stage decides, mid-chain failures are skipped and recorded, final-stage failure falls back to Fable synthesizing survivors, and the result carries recommendation_drift and material_drift signals. It also discloses the trusted flag behavior and denylist scope. No contradiction with annotations.

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

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

The description is long but information-dense; every sentence adds a distinct fact about behavior, usage, or scope. It is front-loaded with the core directional/sequential concept and the sibling contrast. It could be tightened slightly (e.g., the ideation note and the twin expansion are somewhat redundant with the pipeline semantics), but the length is justified by the tool's complexity and the absence of an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 7 parameters, no output schema, and no enums, the description covers the pipeline mechanics, failure handling, result signals, scope boundaries, aliases, defaults, and the trusted flag's activation condition. An agent has everything needed to decide whether to call it and how to construct a valid pipeline. The only minor gap is that the description doesn't detail the exact shape of the recommendation_drift trail, but that is a return-value detail and no output schema exists; the description at least names the signal.

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

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: it explains the pipeline string syntax with aliases ('m3' = minimax, 'opus5' = opus), the 'twin' group token expansion, the default pipeline (minimax > fable), and the relationship between pipeline and models (pipeline ignored when models is given). It also clarifies that repeats are allowed and order matters, which the schema mentions but the description enriches with examples. Slight deduction because the description doesn't add much about context/session/trusted beyond what the schema already says, but the pipeline semantics are genuinely enriched.

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

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

The description opens with 'DIRECTIONAL, SEQUENTIAL — the relay counterpart to ask_council' and immediately distinguishes the chain from the council: ordered pipeline vs parallel synthesis. It states the specific verb (threads a question through an ordered pipeline) and resource (a chain of models), and names the sibling it is not. An agent can tell it apart from ask_council, ask_debate, and ask without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use the chain over a council: 'Best for two things a council can't do: cost-tiered escalation... and explicit draft → red-team → decide pipelines.' It also gives a negative condition: 'Costs MORE latency than a council... so reserve it for when the ordered refinement is the point.' It names the alternative (ask_council) and the scope boundary (same scope as ask, with refused domains listed). This is explicit 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.

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true. The description adds meaningful behavioral context: cost ('one model call per participant per round plus the synthesis'), interactive picker behavior, the `attack_premise` mechanics (two extra calls, requires 3+ seats and 2+ rounds), and alias handling. It does not contradict annotations and provides transparency beyond the schema flags.

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

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

The description is long but densely informative, front-loading the core concept and differentiation. Every sentence serves a purpose: definition, contrast, usage, parameters, cost, scope, aliases. It is not padded; the length is justified by the tool's complexity. It could be slightly tighter, but it remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with no output schema, the description covers most critical aspects: usage, parameters, costs, scope, aliases, and interactive behavior. It hints at the output format (MAP OF THE DISAGREEMENT) but does not fully describe its structure. It also lacks explicit error or fallback behaviors, but overall it is thorough enough for an agent to invoke correctly.

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

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 value: it explains default bench behavior, alias mapping, the `attack_premise` preconditions, and the `interactive` picker interaction. It also clarifies that `context_ref` pulls pre-saved context and that missing keys are non-fatal. These details go beyond the schema descriptions.

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

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

The description opens with 'DIVERGENT, MULTI-ROUND — a brainstorming CONFERENCE where several models argue a topic TOGETHER over rounds' and clearly states the output (a MAP OF THE DISAGREEMENT). It explicitly differentiates from `ask_council` by contrasting the interaction model. The verb is specific ('conduct a conference'), the resource is the models, and it is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use it ('use it for open-ended ideation and design exploration') and contrasts it with `ask_council` ('models answer in isolation, then reconcile'). It also gives scope boundaries ('conceptual software/engineering ideation is in scope; direct offensive-security asks and non-software domains are refused'). This gives clear selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations provide only minimal safety flags, so the description carries the full burden, and it delivers: it discloses slowness, one-of-N caveats, result signals (`consensus`, `material_disagreement`, `sources`), anonymization of panel answers, synthesizer fallback, provider-specific behavior, and trusted-mode semantics. No contradiction with the annotations.

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

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

The description is accurate and dense but extremely long and formatted as a single wall of text, which hurts scannability. It front-loads the key usage directive, but it repeats details already present in the schema descriptions (e.g., twin expansion, tier defaults) and would benefit from bullets or section breaks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates well by explaining what the result contains: `consensus`, `material_disagreement`, `sources` with per-model `recommendation`, and a `synthesis` block. It also covers availability, refusal scope, fallback behavior, and configuration-dependent behavior, so the agent has what it needs to call and interpret the tool.

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

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 goes far beyond field names: it explains the `twin` group token expansion, `tier` meaning relative to `models`, provider-scoped council behavior, synthesizer fallback, and unconfigured-model skipping. This is substantial meaning that the schema alone does not convey.

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

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

The description states a specific action: ask several models the same software/engineering question and get one Fable-synthesized answer. It distinguishes itself from `ask` by framing itself for contentious or hard-to-reverse decisions, so an agent can tell siblings apart without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is explicitly conditioned: use for hard-to-reverse decisions, divergent brainstorming, or multi-model cross-checking; do NOT use for routine questions, defaulting to `ask`. It even limits to at most one council call per problem and tells the agent to check `quorum`/`degraded`, which is actionable routing guidance beyond any schema field.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the annotations, the description discloses the adversarial flow, deterministic ledger-based outcome with specific resolution values, degradation to a single-critic pass, and the cost of up to four sequential model calls. None of this contradicts the annotations, and it adds meaningful operational context.

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

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

The description is long but dense and every sentence earns its place: mechanism first, then differentiation, usage, parameter guidance, cost, scope, and aliases. It is front-loaded with the core concept and avoids filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-model tool with no output schema, the description is thorough: it explains mechanism, outcome resolution values, cost, failure/degradation behavior, scope exclusions, and parameter configuration. An agent has enough to decide when to invoke it and how to configure it correctly.

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

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

Although schema coverage is 100%, the description adds real parameter semantics: examples for proposer/opponent, aliases, the default fable-vs-minimax pairing, the requirement to keep the adjudicator off the debating pair, and the meaning of rounds. This goes well beyond the schema's field names and defaults.

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

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

The description states a specific mechanism: pit two models against each other over a claims ledger, then have a third adjudicate. It explicitly contrasts with ask_council and ask_chain, making the tool's identity and unique role unambiguous even before opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-to-use guidance ('genuinely contentious, hard-to-reverse SOFTWARE decision') and explicit when-not-to ('not for questions with a clear answer'). It also names alternatives, notes cost ('most expensive mode... use it sparingly'), and states scope limits such as refused offensive-security and non-software domain questions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: it is free, local, instant, with no model call, no cost, and no network. It also discloses the behavioral constraint that harnesses truncate standing instructions at ~2 KB, explaining why the tool exists and what portion it returns.

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

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

Front-loaded with the key value proposition (free, local, instant) before the topic guidance. It is dense and slightly long, but each clause maps to a usable decision cue; minor redundancy between description and schema topic list keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-param, no-output-schema help tool, the description fully explains what is returned per topic and when to call it. Nothing an agent needs to invoke it correctly is missing, and the lack of an output schema is compensated by the per-topic content description.

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

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

Schema coverage is 100% and the enum already documents each topic, so the baseline is 3. The description adds real semantic value beyond the schema by attaching behavior to topics, e.g. for 'refused' it says 'reframe, never resend the same question' and for 'context' it explains the paste-once-by-key model, which the schema only gestures at.

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

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

States a specific verb and resource: it returns the portion of this server's manual that does not fit in the standing instructions. This clearly distinguishes it from the ask_* siblings (which make model calls) and the context_* siblings (which manage the shared bus). An agent can tell exactly what this does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Call it when:' block enumerates four concrete trigger scenarios (refused status, re-pasting context, configuring councils, wanting the tool menu) and maps each to a topic value. It also guides speculative use ('cheap enough to call speculatively — prefer it over guessing at an argument'), which is direct when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Describes non-obvious behavior: state persists across calls under the required `session` key, a killed claim stays dead, and a deterministic CODE clerk rather than a model decides outcomes. It also discloses the sandboxed code-execution path, the `trusted` flag's env-var dependency, and the metamorphic stability check — far beyond what 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.

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

The description is long and dense, covering many behaviors, but it is front-loaded with the core adversarial-ledger concept and organized from mechanics to usage to advanced options. Some redundancy with schema parameter descriptions exists, yet most sentences earn their place given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still specifies the return shape: 'survived/killed/open/crucible split plus per-model reputation.' It also covers security refusal, state persistence, model-lab constraints, sandbox execution, and advanced flags, making the tool fully understandable without external references.

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

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

Although schema coverage is 100%, the description adds substantial meaning: assertor/falsifier must resolve to different labs, aliases like 'm3'=minimax, `context` must contain the corpus for verbatim receipt checking, `rounds` semantics, and `metamorph` costs extra model calls and yields `stable_unverified`. This is rich, non-redundant parameter context.

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

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: 'a persistent falsification ledger' where an assertor states claims and a falsifier attacks them. It distinguishes itself from siblings by explicitly naming ask_debate as its 'process cousin' and declaring 'Same scope as ask'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear when-to-use guidance is given: 'Use it to grind a contentious, CHECKABLE question down to what actually survives evidence.' It also states exclusions (offensive-security asks and non-software domains are refused) and names ask_debate as a relative. However, it does not fully articulate when a sibling like ask_debate should be preferred over this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false — a moderate safety profile. The description adds substantial context beyond this: the tool is single-turn, direct providers reject `model`, the `trusted` flag runs the denylist in log-only mode only when ASK_FABLE_ALLOW_TRUSTED is set, and content refusals (offensive security, non-software domains) are disclosed. This is rich behavioral disclosure that annotations alone do not carry.

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

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

Long, but the length is earned — the tool has 7 parameters, 19 provider enum values, and multiple behavioral modes. The core purpose is front-loaded in the first sentence, and every subsequent sentence carries a distinct routing, alias, or safety fact. Slightly dense but appropriately so for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, 2-required tool with no output schema, the description is very complete: it covers providers, aliases, model override rules, effort semantics, context usage, multi-turn alternatives, and refusal behavior. The only minor gap is the absence of a described return/error shape, which is somewhat mitigated by the absence of an output schema.

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

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 real value on top: it classifies each provider into categories (cheap direct, local CLI, OAuth, gateway), gives the alias mapping (m3=minimax, gpt=codex, xai=grok), states which providers reject `model`, and specifies which providers honor `effort`. This is beyond what the schema enumerates, though the schema already documents each parameter competently.

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

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

The description opens with a precise statement of what the tool does — 'Ask ONE model — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing' — and enumerates the exact reasoning domains (code structure, data/control flow, routing, architecture). It also names the sibling tools it is not (ask_council, ask) and the per-backend tools it replaces. No ambiguity about verb, resource, or scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit and exhaustive. It states when to prefer cheap direct APIs, when to pass `model` vs omit it, when to call list_models first, when to use ask_council (several models, synthesized answer), when to use ask (multi-turn with oracle='opus'), and when to use a dedicated local CLI over a gateway. It even lists refusal domains. 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.

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

Annotations are thin (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false), so the prose carries the burden and it delivers. It discloses that the draft is never withheld or rewritten and comes back unchanged even on failure, that 'no objections' is not a correctness guarantee, that same-lab reviews are refused when drafted_by is set, and that it costs one model call. No contradiction with annotations.

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

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

The description is long but tightly organized with a front-loaded mode definition followed by clear 'HOW TO READ THE RESULT' and 'WHAT IT DOES NOT DO' sections. For a tool with 8 parameters and no output schema, every block earns its place and nothing reads as filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description properly takes on explaining result semantics: verify.prevented, verify.unbacked_objections, self-quoting verdict, the unchanged answer, and the no-guarantee caveat. It also covers the operational requirements (context, drafted_by) and cost, leaving no critical decision information to inference.

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

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

Schema description coverage is 100% and each parameter already has rich descriptions, so the baseline is 3. The prose mostly restates what the schema says about context, drafted_by, and answer rather than adding new parameter-level meaning. The genuinely new content (prevented vs unbacked_objections, one-call cost) is output/cost semantics rather than parameter semantics.

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

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 ('Review a draft answer that ALREADY EXISTS...') and states the tool returns objections a reviewer could show versus only argue. It explicitly distinguishes itself from siblings by saying 'This is the only mode that takes a finished answer as input' and contrasting ask_council, ask_debate, and ask_falsify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says exactly when to use it ('Reach for this when you have an answer in hand and the cost of it being wrong is high'), names the alternatives, and explains why they differ. It also gives explicit preconditions: pass context or the review only produces opinion, and pass drafted_by to refuse a same-lab review.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description discloses substantial behavioral traits beyond the annotations: the tool is disabled by default and returns a status object unless ASK_FABLE_ALLOW_WEBSEARCH=1 is set; gemini is search-only due to agy's headless policy and a denial aborts the turn; the result format is a findings summary plus Sources list; and harmful tasks are refused. While annotations declare readOnlyHint=false and openWorldHint=true, the description adds the operational constraints and side-effect nuances that an agent needs.

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

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

The description is dense and front-loaded with the core purpose, and every sentence carries useful information. However, it is a single long run-on paragraph with many parenthetical asides and some redundancy (e.g., gemini's search-only nature is explained both in the description and schema), which slightly hurts parseability. It earns high marks for content but not for concise structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity — multiple backends, an opt-in configuration, CLI/OAuth requirements, and a refusal policy — the description covers all operational aspects an agent needs: prerequisites, model-specific behaviors, output format, disabled behavior, and safety restrictions. No output schema exists, but the description explicitly states the return shape, which is sufficient.

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

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

Although schema coverage is 100%, the description enriches parameter meaning substantially. It explains which model is the default (grok), why gemini is search-only (agy policy denies page fetch and aborts on denial), how `context` is meant to hold the artifact being researched, and when `trusted` is honored (log-only denylist only when ASK_FABLE_ALLOW_TRUSTED is set). This goes well beyond the schema's own parameter descriptions.

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

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

The description opens by stating a precise verb+resource combination: an 'OPT-IN web-search / OSINT research agent' that runs a model with live web search and returns a sourced, cited answer. It explicitly distinguishes itself from every other ask_* tool by noting they are toolless and cannot browse, and enumerates concrete use cases (current facts, versions/pricing/releases, who/what-is, OSINT). This makes the tool's purpose unmistakable and clearly differentiated from its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 for current/'latest' facts, version/pricing/release lookups, who/what-is research, and open-source intelligence. It also provides when-not-to-use and alternative selection: use grok or a Claude model when the task needs page content instead of gemini, and contrasts with all other toolless ask_* tools. The disabled-by-default note and required CLI/OAuth prerequisites further clarify invocation conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description goes far beyond the annotations: it discloses the exact skip list (.git, node_modules, virtualenvs, binaries, oversize files, secret blocklist shared with context_pack), that the SQLite index lives OUTSIDE the repo, that embeddings are opt-in with fail-safe host fallback via ASK_FABLE_EMBED_HOSTS, the degraded keyword-ranking behavior, and that it returns file/chunk/embedding counts. It also reconciles destructiveHint=true by clarifying the tool is 'Read-only with respect to the repo' — the destructive action applies only to the index, which it explicitly says it refreshes.

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

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

The description is long but every sentence carries operational value for a complex tool: workflow, skip rules, storage location, incremental behavior, embedding fallback chain, environment variables, and safety guarantee. It is front-loaded with the primary purpose and the sibling link before detailing behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with zero required parameters and no output schema, the description is exceptionally complete: it covers prerequisites (embedded host env var), failure modes (degraded keyword search), side effects (index refresh), scope (configured project root), and return value shape (counts). An agent can predict the tool's behavior across success and partial-failure scenarios without needing the output schema.

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

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

Schema coverage is 100% — the single `rebuild` parameter is already fully documented in the schema ('Re-chunk and re-embed every file even when its content hash is unchanged (default false: incremental)'). The description's mention of 'Incremental: unchanged files keep their embeddings' reinforces but does not meaningfully extend the schema. Baseline 3 is appropriate since the schema carries the semantic weight.

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

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

The opening sentence names a specific verb ('Build or refresh') and resource ('local code+docs index'), and immediately names the downstream sibling tool `code_search`. This cleanly distinguishes it from the dozens of ask_*/context_* siblings in the tool list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description establishes the workflow ('then search it with code_search') and explains when the `rebuild` flag is appropriate versus the default incremental run. It gives clear context for when to invoke the tool, though it never states explicit exclusions or alternative tools for the indexing task itself — which is reasonable since no sibling performs this role.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark it readOnly/idempotent/non-destructive, and the description goes well beyond them: hybrid FTS5+embedding ranking, reciprocal-rank fusion, keyword-only degradation with a degraded note, opt-in rerank behavior, and pre-index behavior. No contradiction with annotations.

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

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

Four dense sentences, front-loaded with the core behavior and then moving to ranking, degradation, rerank, and prerequisite. No filler; each sentence adds operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, it covers the return format (window references), the ranking/behavior nuances, the optional rerank, and the not-indexed precondition. There is no obvious missing detail an agent needs to decide or invoke correctly.

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

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

Schema describes all three parameters with defaults, max, and behavior for rerank, so the description adds little param-level meaning beyond 'natural-language or code search query' already in schema. It enriches context on output and ranking, not on the parameters themselves.

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

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

States a specific verb ('Search') and resource ('local project index built by code_index'), and specifies the output form ('windows ... with file:start-end references'). It also distinguishes itself from cruder alternatives ('cheaper and more targeted than grepping or reading whole files'), which positions it clearly among the toolset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear when-to-use context: it is the targeted way to query the local code index, cheaper than grepping or reading whole files, and depends on code_index having run ('Returns not_indexed until code_index has run'). It does not explicitly enumerate exclusions against sibling ask/context tools, but the context is strong enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

It explicitly discloses the persistence side effect: 'written to ask_fable's config file, overriding the matching ASK_FABLE_*_COUNCIL env default.' It also states the return value and file-path behavior. This adds meaningful behavioral context beyond the annotations, which only signal idempotence and non-read-only.

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

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

The description is dense but front-loaded: the first clause gives purpose and side effect, and subsequent clauses organize provider-specific semantics. Some redundancy with the schema exists, but each sentence carries useful operational detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 the return value, file path, user-confirmation requirement, grounding step, persistence behavior, and provider-specific parameter applicability. An agent has enough to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, and the schema already documents provider enums, model token forms, synthesizer omission behavior, and `ask_model` usage. The description largely restates this information, adding only marginal context such as 'that `ask_council(provider=…)` should use by default.'

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

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

The description opens with a specific action and resource: 'Save the user's chosen default council for ONE gateway so it sticks across sessions.' It also names related tools like `ask_council` and `list_models`, making it easy to distinguish this persistent-configuration tool from live query tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context and a mandatory pre-step: 'Confirm the selection with the user first — ground it with `list_models(provider=…)`.' It also explains when each provider-specific parameter is applicable. It does not explicitly rule out sibling configuration tools like `configure_tracing` or `configure_disabled`, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already indicate this is a non-read-only, idempotent operation, and the description adds substantial behavioral detail: changes persist to the config file, no restart is needed, disabled backends disappear from every council/tier, and their tools return kind='disabled' versus 'not configured'. It also explains env var precedence and the effect of set=[], which goes well beyond the annotations.

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

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

The description is compact, dense, and well ordered: core action first, followed by behavioral consequences, token syntax, no-args usage, and precedence rule. Every sentence contributes useful information; there is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 the essential return-related behavior: disabled backends return kind='disabled', and calling with no arguments shows the current denylist. It also covers persistence, env var interaction, and how providers vs individual keys are handled. No critical operational detail is missing for an agent to invoke this correctly.

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

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 practical meaning: examples of oracle keys/aliases and provider names, provider-level disable semantics, and the runtime persistence context. The schema already documents replace/add/remove semantics well; the description enriches it with concrete usage guidance without repeating the schema verbatim.

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

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: 'Turn oracles/providers OFF (or back on) at runtime.' It clearly distinguishes the tool's purpose from sibling tools by explaining the persisted denylist effect and the kind='disabled' behavior. It also covers the no-argument invocation for viewing the denylist, leaving 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear operational context: runtime persistence, no restart required, and precedence of config over the ASK_FABLE_DISABLED env var. It implies when to use this tool (managing disabled backends) but does not explicitly contrast it with alternatives like configure_council or unload_lms_model. That omission prevents a 5, but the context is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Far exceeds the annotations (which only say not-read-only, idempotent, non-destructive). The description discloses the exact side effect (config file write), the precedence relationship with env vars, the timing ('applies on the next call'), and the distinct consequences of each mode including redaction and markdown saving.

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

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

Front-loaded with the core action and effect, and the operational details (config precedence, no restart) follow logically. It is dense with long parentheticals and duplicates much of the schema's parameter text, which costs it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description states the return value ('the effective settings and the config path') and covers persistence, timing, and scope of effect. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100% and the enum is documented there, so the baseline is 3. The description adds the combinatorial rule 'Pass either or both' and reiterates the override behavior, which is meaningful beyond the schema but largely redundant with the per-parameter descriptions.

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

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

States a specific verb and resource ('Toggle reasoning-trace capture at runtime') plus the persistence scope ('persisted across sessions'). It is clearly distinguishable from sibling read tools like trace_list and trace_get, since this one mutates configuration rather than reading traces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong operational context: it writes the ask_fable config file, overrides the ASK_FABLE_TRACE_MODE / ASK_FABLE_STREAM_REASONING env defaults, requires no ~/.claude.json edit or restart, and applies on the next call. It does not name a competing tool to use instead, but no sibling offers this capability, so the missing exclusion is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark destructiveHint true and readOnlyHint false, and the description reinforces this with 'Destructive/overwriting' and the overwrite-on-reuse warning. It adds valuable context beyond annotations: the store is shared across agents, pack produces a budgeted bundle, and reading with context_read first is recommended.

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

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

The description is dense but front-loaded, opening with the resource and then detailing each operation in order. Some wording duplicates the schema and the final 'Destructive/overwriting' tag is redundant with annotations, but overall it is appropriately sized for a three-mode tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-operation tool with no output schema, the description covers the key behaviors: what each op does, path syntax, key reuse, overwrite semantics, and cross-agent sharing. It could have clarified return/confirmation behavior and per-op parameter exclusion, but those are minor given the schema and annotations.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description mostly restates the op-specific behavior already present in the schema for value, paths, max_chars, and description, and adds no new parameter-level semantics beyond the global reuse and sharing warning.

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

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

The description names the resource (shared context bus) and makes the generic verb 'Change' concrete by enumerating the three operations: write stores a value, pack bundles repo files, and delete removes a key. It also differentiates itself from the sibling context_read by instructing the agent to read with context_read first.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage guidance: paste a large blob once and reference it via context_ref instead of re-pasting it, use pack for repo files, and read with context_read before relying on shared content. It also warns that the store is shared by every agent and that reusing a key overwrites it, telling the agent when extra caution is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description discloses exact behavior beyond annotations: `not_found` when a key is unset, metadata returned with each blob, and the important distinction that list mode never returns full values. This is especially valuable because there is no output schema.

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

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

Two well-structured sentences deliver the mode distinction, return format, missing-key behavior, read-only guarantee, and a pointer to `context_ref`. No filler; information is front-loaded and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 fully covers both invocation forms, the shape of returned data, the missing-key case, the read-only nature, and how the tool fits into the context-ref workflow. An agent has everything needed to invoke and interpret results correctly.

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

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

The input schema already documents `key` and the omit-to-list behavior at 100% coverage, so the baseline applies. The description adds return-behavior context (size, age, description, not_found) but no new parameter constraints or format details, so it doesn't substantially exceed schema coverage.

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

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

States a specific verb ('Read') and resource ('shared context bus'), then precisely distinguishes the two invocation modes: pass `key` to get a blob, or omit `key` to list stored keys. It also mentions `context_ref` as the referencing counterpart, which helps separate it from related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives two concrete use cases: inspect a single blob, or discover available keys before re-pasting via `context_ref`. It doesn't enumerate exclusions or compare against sibling tools, but the usage context is clear enough for an agent to decide when to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, but the description goes beyond them: it states 'makes NO paid model call and NEVER perturbs state' and details exactly which checks are performed ('CLI presence and --version, whether an API key is set, and the breaker's read-only snapshot'). This adds genuine behavioral context about side effects and cost, exceeding what the annotations alone provide.

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

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

The description is three sentences: purpose and when-to-use, output summary, and safety constraints. It is front-loaded with 'Read-only health check', uses imperative 'REACH FOR THIS', and every clause serves a purpose. No filler, and the structure guides the agent from 'what' to 'when' to 'what it costs'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, no-output-schema tool, the description fully covers behavior, side effects, and expected report contents (reachability, model, timeout, breaker gate, fix line, and rollup status). An agent knows exactly what it will get and what it costs, making it complete enough for correct invocation decisions.

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

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

The input schema is empty with 0 parameters, so the baseline per the rubric is 4. The description appropriately focuses on tool behavior rather than parameter details, since there are no parameters to document. It adds no parameter semantics because there are none to describe.

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

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

The description opens with 'Read-only health check of every reasoning backend', a specific verb/resource pairing that clearly defines scope. It then lists concrete trigger conditions ('when a council came back degraded, an oracle is unexpectedly missing') which sharply distinguishes it from sibling ask_* and configure_* tools, and enumerates exactly what it reports (reachability, resolved model, timeout, circuit-breaker gate, fix line). This leaves no ambiguity about the tool's purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when to reach for it: 'REACH FOR THIS when a council came back degraded...' and adds the wise precaution 'before relying on it'. It also clarifies the safety profile ('Cheap and safe to call speculatively') which informs usage frequency. While it doesn't name sibling tools by name, the explicit when-conditions are sufficient to route an agent correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only'. It additionally discloses the best-effort behavior: 'an unreachable control page returns a status error, never a crash.' This adds meaningful failure-mode context beyond the structured annotations.

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

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

The description is dense but well-organized: core purpose and metrics first, usage trigger second, and failure caveat last. Every sentence adds useful information, and there is no filler or repetition of schema contents.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description lists all relevant data categories and the error behavior, making it clear what the agent can expect. The combination of usage context, sibling relationship, and failure semantics fully covers what an agent needs to invoke this zero-parameter read-only tool correctly.

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

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

The tool takes zero parameters and the schema has no properties, so there is no parameter burden for the description to carry. The baseline for zero-parameter tools is 4, and the description appropriately spends no space on parameter details.

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

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

The description begins with a specific verb and resource: 'Read-only GPU and host status from the operator's Control panel'. It enumerates the exact metrics returned (GPU utilization, VRAM, temperature, fan, power, process holders, systemd states, loaded models, warnings), which leaves no ambiguity about what the tool does. It also distinguishes itself from sibling tools by explicitly referencing ask_lms and the local-model memory context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contains an explicit trigger: 'REACH FOR THIS when the user asks how the GPU/box is doing, or before offering a local-model decision that may not fit in memory.' It also names the relevant sibling (ask_lms) and clarifies its relationship, giving the agent a concrete routing rule rather than leaving usage to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark it read-only and idempotent, and the description goes well beyond them by disclosing network behavior ('refresh' fetch live vs configured defaults), interactive picker behavior, VRAM classification for lmstudio, and the no-key property for Atlas/OpenRouter. This adds substantial context beyond the structured hints.

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

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

The description is dense but well organized: purpose first, then provider catalogue details, then parameter-specific qualifiers, ending with a one-word safety tag. Every sentence contributes differentiating behavior or usage context, and no space is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (six parameters, five enum values, no output schema), the description covers the important return-relevant details: what each provider offers, when network access is used, what task ranking does, and what the picker will do. An agent has enough to select parameters correctly.

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

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 improves on that by explaining the meaning of ranking ('task'), the interactive picker, and the 'all' extension for Ali. It mostly reinforces the schema rather than adding wholly new semantics, but the additions are useful.

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

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

States a specific verb and resource: 'List the available models for one gateway'. It further disambiguates itself by enumerating the five provider catalogues, so an agent can tell exactly what it does and how it differs from the sibling ask/configure tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context ('before spending a call', 'offer a concrete choice') and explains provider-specific behaviors such as which catalogues are free or need no key. It does not explicitly state when not to use the tool or name alternative tools, but the guidance is strong enough for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark destructiveHint=true and idempotentHint=true; the description adds context by disclosing the optional file dump and the effect on the next `ask`. It does not contradict the annotations, and the remaining details (file destination, irreversibility without save) are left to the schema/defaults.

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

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

A single sentence that front-loads the action and outcome with no filler. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The definition is largely complete for a low-complexity, fully optional-parameter tool: annotations cover safety, schema covers all parameters, and the description covers purpose and effect. It loses a point because the description itself scopes to 'Fable' and `ask` while the model parameter shows it also handles opus5/`ask_opus5`, and no return value/file-path behavior is mentioned in the absence of an output schema.

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

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

Schema description coverage is 100%, so the schema already documents save, model, and session. The tool description only repeats 'optionally to a file' and 'on that key' without adding new parameter-level meaning; baseline 3 applies.

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

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

The description uses a specific verb+resource: 'Dump ... and clear a Fable conversation session', and explains the outcome ('the next `ask` on that key starts a fresh topic'). This clearly distinguishes reset_session from the ask_* and session_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys when to use the tool: when you want to start a fresh topic for a given session key. The schema's model parameter description adds guidance for choosing between `ask` and `ask_opus5` namespaces, but the tool description itself does not explicitly state when not to use it or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover readOnlyHint/idempotentHint/destructiveHint, so the description earns credit for what it adds: 'makes no model call', the ~5 min stale threshold behind the default, and the important visibility-only guarantee that sessions never affect oracle answers and oracles only see explicitly passed question/context. It does not disclose volume/truncation behavior, though limit=200 max suggests bounded output.

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

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

Front-loaded with the 'COORDINATION — the operator dashboard' role, then scope, then defaults, then usage — a sensible ordering with no filler sentences. It is on the long side for a three-parameter list tool, and the read-only/model-call sentence partially restates the annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating the returned fields per entry. Combined with default behavior, stale threshold, and the visibility guarantee, an agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 67% and the description meaningfully supplements it: it states the defaults (this project, active_only:true) in one place and explains the ~5 minute stale threshold that the schema's active_only description only gestures at ('recent heartbeat'). It says nothing about `limit`, so it does not fully close the coverage gap.

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

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

Opens with a specific verb+resource ('Lists ask_fable sessions across instances on this machine') and names the concrete instances (opencode / Claude Code / salient windows). The scope statement plus the enumerated entry fields ('session key, agent_id, latest question, oracle, status, heartbeat age, turn count') makes it clearly distinct from ask_* siblings and from session_peek/session_stats without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear use context ('Use it to avoid duplicate work or watch the live fleet') and states which flag selects which mode: active_only:false for retained history, all_projects:true for the whole machine. It stops short of an explicit when-not-to-use or a named alternative among siblings (session_peek, session_stats, trace_list), so a 4 rather than a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-redundant context: results are 'bounded by retention', it 'makes no model call', and it 'never feeds back into an oracle's context' — the last point materially shapes how an agent should reason about using it.

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

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

Front-loaded with the category ('COORDINATION'), then the core action, then use cases, then behavioral caveats. Three sentences with little waste, though the trailing session_list/oracle-context sentence is slightly tangential to invoking this specific tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description compensates by stating what returns ('the complete conversation bounded by retention'), and the retention bound is an important completeness detail. For a 2-parameter read tool with full annotation coverage, nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description's 'Optionally scope to one agent_id' merely restates the schema's 'restrict to one agent's turns' without adding format, default, or edge-case detail. Baseline 3 applies when the schema carries the semantics.

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

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, across instances') and explicitly contrasts its visibility-only nature with the oracle-feeding siblings via the session_list comparison. An agent can distinguish it from session_list, context_read, and trace_get without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives two concrete use cases ('before joining the work' and 'to recover a finding another instance produced') that tell the agent when this tool is the right pick. It stops short of naming an explicit alternative tool to use instead (e.g. session_list vs context_read) or stating when not to use it, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint/idempotent/destructive=false, so 'Read-only, makes no model call' largely restates structured data. However, the description adds real behavioral context the annotations don't cover: the default 24h window, the `window_s: 0` escape hatch, the all-projects scope, and the returned breakdowns (`fresh_sessions` vs `total_sessions`, `attributed_turns`/`unknown_turns`).

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

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

Dense but front-loaded: the coordination scope and the sibling distinction come first, then defaults, then returned fields, then use cases. Every clause carries information, though it is a long single paragraph rather than crisply segmented.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating what the tool returns (turn counts by status/oracle/agent, fresh vs total sessions, attributed/unknown turns). Combined with the scope and window semantics, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and both parameters are fully documented in the schema, including the `window_s: 0` semantics. The description's param notes largely duplicate the schema text, so this is the baseline 3 rather than added value.

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

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

Opens with a specific verb+resource+scope ('aggregated oracle usage across ALL instances on this machine') and explicitly contrasts itself with the sibling `stats`, which only sees the current instance's audit log. An agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States when to use it (vs `stats`), names the concrete questions it answers ('which agents are burning the most oracle calls?', 'how is the fleet doing today?'), and gives the two modes via `all_projects`. 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.

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, and the description adds meaningful context beyond them: no model call is made, results are never cached, and council/chain records carry quorum/consensus/synth_fallback. It still doesn't say whether results are paginated or how stale the aggregation is, so it isn't exhaustive.

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

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

Front-loads purpose, then window/by, then filters, then reporting fields, then examples. Every sentence carries information (what is aggregated, how it can be sliced, what is returned, what constraints apply) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by enumerating the returned metrics (calls/allowed/refused/errors, avg and p95 latency, error_rate, totals). Combined with the filter and window semantics, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% and the by enum's own description already explains provider vs model attribution, so the schema does the heavy lifting. The prose restates only three of the eight bucket keys ('model', 'session', 'day'), adding little syntax or semantics beyond the schema's own text.

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

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

States a specific verb and resource: read-only usage/health stats aggregated from the ask_fable audit log, with named bucket dimensions (by) and time windows. The scope ('without spelunking JSONL') clearly separates it from the ask_* generation tools and trace/log inspectors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete motivating questions ('is GLM erroring a lot today?', 'how slow are councils this week?') that make the intended use obvious. It does not, however, explicitly name an alternative or say when not to use it (e.g., vs session_stats), so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are ordered and include artifact references, but says nothing about truncation via max_chars or what include_content gates.

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

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

A single front-loaded sentence with no filler — appropriately terse. The terseness is a coverage problem rather than a structure problem, so it keeps a high score here.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, 0% parameter documentation, and no usage routing, the definition is too thin for a tool with two meaningful tuning parameters. The one sentence only partially signals what comes back.

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

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

Schema description coverage is 0% for three parameters, and the description names none of them. max_chars (truncation limits) and include_content (payload verbosity) are non-obvious and carry real behavioral consequences that go entirely undocumented.

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

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

Specific verb ('Read') plus a precise resource ('ordered events and artifact references for one trace'), which clearly separates it from trace_list. It does not name siblings explicitly, but the singular-trace scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance and no mention of alternatives such as trace_list or session_peek. The agent must infer from the name alone that this is the drill-down companion to trace_list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact not in the annotations — that raw trace content is excluded from results — but says nothing about ordering, pagination behavior, or result size.

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

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

A single tight sentence with no filler, and the scope qualifier is front-loaded. It is efficient, though its brevity is partly under-specification rather than disciplined compression.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Seven unlabeled optional parameters, no output schema, and no annotation gaps filled — an agent has no way to learn what 'project', 'session', or 'provider' accept or how paging works. For a filter-heavy list tool this is substantially incomplete.

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

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

All 7 parameters (tool, limit, before, status, project, session, provider) have 0% schema description coverage, so the description carries the full burden and largely fails it: not one filter, the limit cap, or the 'before' cursor is explained. Only the word 'recent' weakly hints at time-ordered retrieval.

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

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

States a specific verb ('List') and resource ('correlated tool traces') plus a scope qualifier ('without raw content'), which distinguishes it meaningfully from trace_get's single-trace retrieval. It never names trace_get, so the differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this rather than trace_get, session_peek, or stats, and no prerequisites or filtering conditions are described. An agent must infer usage entirely from the name and sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark this destructive and idempotent, and the description reinforces and expands on both: it discards a resident model, refuses while an `ask_lms` call is in flight, waits for confirmation, and reports bytes freed plus what remains resident. There is no contradiction between description and annotations.

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

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

The description is dense but every sentence serves a purpose: operator warning first, then prerequisite, then in-flight refusal and result reporting, then idempotence. It is front-loaded with the most critical safety information and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter destructive tool with no output schema, the description covers preconditions, refusal behavior, return information (bytes freed and resident models), and idempotence. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, and the schema already explains that `model` is a loaded model key with an example and a pointer to `list_lms_models`. The top-level description does not add substantially new parameter semantics, but it does not need to given full schema coverage.

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

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

The opening sentence uses a specific verb ('unload') and resource ('model from the operator's LM Studio server') with a clear goal ('free memory'). No sibling tool performs unloading, so there is no ambiguity about which tool to select.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when not to call it: 'never call this without an explicit request or confirmation from the user' because it discards a resident model. It also names the prerequisite (`list_lms_models`), the blocked `ask_lms` signal (`unload_offer`), and the in-flight refusal condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.