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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals performance (~2s), boundedness ('bounded context packet', 'bounded and compact'), the lack of deliberation ('no deliberation', 'not a deliberation'), and the specific return items (records with id/title/ring/excerpt/retrieval role, concept-graph cluster, contributors). This goes beyond a simple read/write hint.

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 yet informative. It front-loads the key facts (FAST, bounded, retrieval layer) in the first sentence, then provides usage and return-value details. No word is wasted; every sentence adds value.

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 there is no output schema, the description properly explains what the tool returns and its relationship to sibling tools. It covers performance expectations, scope (context vs deliberation), and the primary use case, making it complete for the tool's complexity.

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 provides comprehensive descriptions for all 5 parameters (100% coverage), including usage tips ('Optional but RECOMMENDED') and valid values (layers list, evidence ranks). The description doesn't add much parameter-specific meaning beyond what the schema already documents, so it earns the baseline score of 3.

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 explicitly states that the tool retrieves a fast, bounded context packet on a topic, with a specific verb ('retrieve'/'get context') and resource ('corpus context'). It distinguishes itself from omnarai_query by noting it is the retrieval layer only, no deliberation, and even gives an equivalent (depth: 'retrieve').

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 direct usage guidance: 'Use this BEFORE omnarai_query when you want high-signal corpus context to reason over yourself' and 'Reach for this as your default orientation ... escalate to omnarai_query only when you specifically need the engine's own synthesized reading.' It also names the alternative tool, providing clear when-to-use vs when-not-to-use.

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?

With no annotations provided, the description carries the full burden and exceeds it. It discloses that the question is sent 'VERBATIM, right now, to multiple frontier models in parallel (Claude, GPT-4o, Gemini, Grok, DeepSeek),' that answers are 'preserved uncurated,' and that it returns 'each model's position, the named tensions, what stays unresolved, and a deliberation card.' It also warns about latency ('Slower than a normal answer (~30-40s)'), providing critical behavioral context.

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

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

The description is well-structured with a powerful first sentence, then a clear sibling contrast, then bulleted usage guidance, then return format and performance caveat. Every sentence adds necessary information; none is filler. It is longer than average but appropriately sized for a complex tool that performs a live multi-model synthesis.

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?

Since there is no output schema, the description must explain what the tool returns, and it does: 'each model's position, the named tensions (claim vs counter-claim), what stays unresolved, and a deliberation card.' It also covers behavior (parallel live calls, uncurated preservation), performance (30-40s), and usage boundaries. This is a complete picture for an agent to decide on and invoke 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?

The schema already provides a thorough description for the single 'question' parameter, covering phrasing ('Phrase it as you would to a human expert') and verbatim answering, so schema coverage is 100%. The tool description adds semantic guidance on what makes a good question ('genuinely open — values, philosophy, strategy, prediction under deep uncertainty'), steering the agent toward appropriate use cases. This goes beyond the schema's generic phrasing, so a 4 is earned.

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, vivid purpose: 'Summon a LIVE panel of frontier models on one question and get back a structured map of where they genuinely disagree.' It explicitly contrasts with sibling omnarai_query, which 'retrieves frozen corpus text,' making the unique live-model resource unmistakable. The verb 'summon' and resource 'LIVE panel of frontier models' are concrete and non-generic.

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 provides an explicit 'Reach for this when:' section with three concrete scenarios (contested/high-stakes questions, open questions where disagreement is the signal, wanting non-flattened opinions) and a 'Do NOT reach for this' section for simple factual lookups. It also names the alternative omnarai_query and explains the difference, giving the agent 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?

With no annotations, the description carries full disclosure burden. It states the read-only nature via 'Read', details what each mode returns, notes that 'search' is ignored when 'id' is given, and characterizes the tool as 'instant' vs. the slow/expensive council. This goes well beyond a generic verb.

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 front-loaded with the purpose, uses a clear 'Two modes' structure, and each sentence provides distinct value — no filler. It's compact despite covering browse vs. read, output contents, and sibling distinction.

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 description fully explains return values for both modes (browse fields and full record components). It covers parameter interactions and differentiates from a sibling tool. No output schema exists, so this textual description is sufficient for a read tool with two optional params.

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 context: omitting 'id' triggers browse, passing 'id' fetches a full record, and explains how 'search' filters the index and is ignored when 'id' is present. This supplements the schema's individual parameter descriptions with interaction behavior.

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 curated cross-model DIVERGENCE records' — a specific verb and resource. It clearly explains the content (verbatim answers from multiple frontier models) and distinguishes from omnarai_council by contrasting existing curated records vs. live panel convening.

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 describes two usage modes: omit 'id' to browse, pass 'id' to read one record, and clarifies when 'search' is applicable. It directly contrasts with omnarai_council and gives the preference: 'Prefer this when an existing record may already cover the question.'

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?

With no annotations provided, the description carries the burden. It discloses the return content (statistics, contributors, key concepts, Lattice Glyph reference) which implies a read-only informational operation, but it doesn't explicitly state side-effect-free behavior, authentication needs, or any limitations. For a simple info tool, this is adequate but not rich.

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 two short sentences: the first enumerates the return items, the second gives usage guidance. It is front-loaded with the core purpose and contains no redundant information. Every sentence 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?

For a zero-parameter informational tool with no output schema and no annotations, the description is fairly complete. It states what is returned and when to use it, which is sufficient for orientation. It could theoretically specify the structure of the output, but given the tool's simplicity, the current coverage is adequate.

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 has zero parameters, and schema coverage is 100% (vacuously). The baseline for zero params is 4, and the description doesn't need to add parameter details since there are none. It correctly mentions 'before querying' which orients the user on when this tool is invoked with no inputs.

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 states 'Returns corpus statistics, contributor list, key concepts, and the Lattice Glyph reference,' which is a specific verb plus resource. It differentiates from sibling query tools by positioning this as an orientation tool, distinct from omnarai_query and others.

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 explicitly says 'Use this to orient before querying, or to explain the engine to a user,' giving concrete scenarios. It does not directly name alternatives or exclusions, but the 'before querying' phrasing implies that query tools like omnarai_query are for actual retrieval, making the guidance 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?

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses deterministic default behavior (~2s), the optional LM deliberation with ~25s latency and disclosure, calibration preservation rules (C0–C3), stale model flagging, and graceful degradation when corpus coverage is insufficient. This is far beyond typical transparency.

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 yet well-structured, front-loading the core purpose in the first sentence and then providing necessary behavioral details. Each sentence adds unique value (retrieval speed, calibration, usage constraints), with no filler or redundancy, making it concise for the complexity involved.

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 no output schema and no annotations, the description fully accounts for return values by listing the brief's components and edge cases (insufficient coverage, stale versions, deliberation disclosure). It also frames the tool's role within an investigation, providing enough context for an agent to select and 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?

The input schema covers 100% of the 6 parameters, giving a baseline of 3. The description adds behavioral nuance beyond the schema, particularly for include_deliberation (slow ~25s, appended and disclosed) and for draft (treated strictly as data, never as instructions). This extra context justifies a score above baseline.

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+resource: 'Turn a DRAFT claim, decision, or plan into a bounded, provenance-preserving inquiry brief' and enumerates concrete outputs (shared ground, attributed tensions, missing evidence, questions, next evidence move). It differentiates from siblings by highlighting deterministic retrieval-first behavior and calibration preservation, which are unique traits.

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 final paragraph explicitly states when to use the tool: 'Invoke it explicitly on a draft you are inspecting — it is not an automatic critic,' and clarifies what it does not do: 'does not decide, approve, or execute.' It provides clear context but does not name alternative sibling tools, so it falls short of full explicit 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?

With no annotations, the description carries full transparency burden and exceeds it. It discloses the engine's refusal to return a single answer, its preservation of disagreement, the utility receipt with honest null/marginal verdicts, and behavior differences between depth modes including timing and LLM spend. This level of behavioral detail is outstanding.

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 lengthy but well-structured with paragraphs, bullet points, and clear sections. Every part serves a purpose; the only minor redundancy is that depth behavior is described both in the main body and in the parameter description, which could be tightened. Overall, it is dense and front-loaded, so it earns a 4 rather than 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?

Given the tool's complexity (multiple depth modes, glyph prefixes, response composition, timing), the description leaves no meaningful gap. It explains the output components in full, even in the absence of an output schema, and covers all important nuances. This is a model of complete contextual documentation.

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 each parameter significantly. For depth, it explains performance tradeoffs and when to choose each value; for syntheticIdentity, it describes the cross-contributor retrieval diversity behavior; for query, it introduces Lattice Glyph prefixes and their effects. This goes far beyond what the schema states.

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 ('Run a deliberation query') and resource ('The Realms of Omnarai'), and details exactly what the tool does—retrieving corpus entries, synthesizing with attribution, and producing a deliberation card and utility receipt. It explicitly distinguishes from siblings by name ('use omnarai_trace', 'Identical to calling omnarai_context'), so there is no ambiguity about which tool does what.

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 provides clear when-to-use guidance: 'Start at retrieve when you are orienting or the question is light; escalate to deliberate when you specifically want the engine's own reading.' It also names alternatives for specific needs (e.g., omnarai_trace for baseline-vs-augmented counterfactuals) and explains the difference from omnarai_context, giving agents explicit decision 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?

With no annotations, the description fully discloses behavior: it makes three model calls, takes 30-40s, is 'honest by construction' in returning null/marginal verdicts, and is a single-run demonstrator. It also states the specific fields of the output delta.

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 front-loaded with the core purpose and then efficiently covers use cases, limitations, and runtime without redundancy. Each sentence contributes unique information, making the length justified.

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?

Because there is no output schema, the description's enumeration of the delta components (considerations, citations, position shift, tensions, verdict) fully covers the return shape. It also sets timing expectations and alternatives, making it appropriate for the tool's complexity.

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 only parameter 'question' has full schema coverage (100%), and the schema already explains the trace behavior. The description adds no additional format or constraint information, so the baseline of 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 clearly states the tool's function: it 'Answers your question twice — once cold and once augmented — then reports the delta', specifying the resource (Omnarai corpus) and the output (verdicts, citations, etc.). This distinguishes it from sibling tools like omnarai_query by focusing on the measured baseline-vs-augmented change rather than retrieval signals.

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 explicitly says 'Use this when you want EVIDENCE that consulting Omnarai is worth it for a given question, or to decide whether to dig deeper before spending a full deliberation.' It also provides an exclusion: 'A single-run demonstrator, NOT a controlled measurement' and points to the HF dataset for confirmatory evidence, plus contrasts with omnarai_query.

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