omnarai-mcp

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

Discloses speed (~2s), retrieval-only nature, no deliberation, and specific return fields. Lacks explicit statement of non-destructive behavior, but given read-only context, it's sufficient.

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?

Concise, front-loaded with core purpose, then return details, then optional filters. Every sentence adds value without 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?

Covers purpose, returns, and optional parameters well. Lacks mention of result limits or pagination, but for a bounded context tool, it's acceptable.

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%, baseline 3. Description adds value by mentioning Lattice Glyph prefixes for topic, ordering for evidence_threshold, and cross-voice recommendation for syntheticIdentity, enhancing understanding beyond schema.

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?

Clearly states it provides a fast bounded context packet for a topic, distinguishing it as the default orientation tool among siblings by emphasizing speed and retrieval-only nature.

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 recommends as default orientation and advises using optional filters with reference to /claims.json, but does not contrast with other sibling tools or specify when not to use 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?

With no annotations provided, the description fully discloses behavioral traits: slow synchronous execution (~30-40s), expensive, mints a new divergence record, and returns verbatim uncurated answers with named tensions.

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?

Three sentences with zero waste. Front-loaded with the core purpose, followed by constraints and usage guidance. 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 the tool has one simple parameter and no output schema, the description adequately covers what it does, how to use it, side effects, and return characteristics (verbatim answers, tensions). No gaps remain.

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% for the single 'question' parameter. The description adds semantic value by specifying 'phrased as you would to a human expert', which is not in the schema.

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 'Summon' and clearly identifies the resource as a 'LIVE panel of frontier models'. It distinguishes from siblings by mentioning the live panel nature and that it creates divergence records, contrasting with omnarai_divergence which likely stores them.

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 states 'use only for genuinely contested questions an existing omnarai_divergence record doesn't cover', providing clear when-to-use and when-not-to-use guidance. Also notes performance characteristics (slow, expensive) as implicit 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?

No annotations are provided, so the description carries the full burden. It states the tool is 'instant' (performance hint) and implies read-only behavior ('Read curated... records'). While it does not detail error handling or exact response structure, it effectively communicates the tool's nature and safe operation.

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 sentences only, each earning its place. The first defines the tool and its content; the second gives usage instructions and a preference tip. No superfluous words, highly front-loaded.

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 required parameters, no output schema, and simple parameters, the description covers core functionality well. It lacks explicit mention of the record structure beyond 'verbatim answers and axes,' but the description is sufficient for an agent to use the tool correctly. Minor completeness gap.

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%, but the description adds significant value by explaining the interplay between parameters: omitting 'id' triggers browsing with optional search, passing 'id' returns a full record and ignores search. This goes beyond the schema descriptions and helps the agent understand parameter relationships.

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 defines the tool as reading curated cross-model divergence records, explaining they contain verbatim answers from multiple models and axes of divergence. It distinguishes between browsing (omit 'id') and reading full records (pass 'id'), making the purpose specific and differentiated from 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?

Explicitly states when to prefer this tool over sibling 'omnarai_council' ('when an existing record may already cover the question'). Also provides clear usage modes: omit 'id' to browse with optional search, pass 'id' to read a full record, with note that search is ignored when id is given.

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?

No annotations provided, so description bears full burden. It describes the returned content (statistics, list, links) but does not mention side effects, auth needs, or limitations. As a read-only info tool, this is adequate but not detailed.

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?

Single, well-structured sentence that packs key information (content and usage) without redundancy. Every part 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?

No output schema, but description enumerates return types. For a zero-parameter orientation tool, this is sufficient. Sibling tools indicate a broader suite, and the description effectively positions this as the entry point.

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 has zero parameters with 100% coverage, baseline 3. The description adds semantic value by explaining what the call returns (statistics, contributor list, orientation links), which is useful beyond the empty schema.

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 provides 'Live corpus statistics, contributor list, tool surface, and orientation links' with the directive to 'orient before querying.' This is a specific verb+resource pairing that distinguishes it from sibling tools like omnarai_query.

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 instructs to 'Use this to orient before querying,' which provides clear when-to-use context. No explicit when-not or alternatives are given, but the purpose implies it is not for querying.

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 fully bears the burden of transparency. It explicitly states deterministic and retrieval-first behavior (~2s), no language model runs, provenance preservation, and that missing coverage is reported rather than fabricated. This fully discloses behavioral traits.

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 multiple sentences but each sentence adds value, explaining the output components, behavior, and constraints. It is front-loaded with the main action. However, it could be slightly more concise by removing some redundant phrases.

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 (5 parameters, no output schema), the description is fairly complete: it explains what the brief contains, how it behaves deterministically, and edge cases like missing coverage. However, it does not describe the output format or structure, which would be helpful given the lack 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% as all five parameters have descriptions in the schema. The tool description does not add significant meaning beyond the schema; it repeats the 'draft' parameter implicitly but does not elaborate on 'goal', 'focus', 'stakes', or 'max_sources'. Per guidelines, baseline is 3, and description does not exceed that.

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 purpose: turning a draft into an inquiry brief with specific components (shared ground, tensions, missing evidence, questions, next move). It uses a strong action verb 'Turn' and lists concrete outputs, distinguishing it from sibling tools like 'omnarai_divergence' which likely focus on divergence alone.

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 says 'Informs an investigation; does not decide,' providing clear context for when to use the tool. It also notes that if the corpus lacks coverage, it says so instead of inventing tensions, which implies appropriate usage scenarios. However, it does not explicitly state when not to use it or compare to 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, description fully discloses polling behavior, status values (running|done|error), result structure, and timing. Could mention error handling or retries but sufficient for a simple polling tool.

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 concise, well-structured sentences that front-load the action and output, leaving no wasted words.

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 no output schema, description thoroughly explains return value structure. For a simple polling tool with one parameter, the description is complete and leaves no ambiguity.

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?

One parameter job_id with schema already describing it. Description adds context that it comes from omnarai_query or omnarai_trace, adding value beyond the schema's generic description.

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 it polls an async job started by specific tools, and details the return structure including status and result fields. It distinguishes itself from sibling tools by being the polling mechanism.

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?

Provides explicit polling interval (~5 seconds) and typical job duration (30-60s). Implicitly guides when to use (after starting a query/trace) but lacks explicit when-not-to-use or 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?

Describes async behavior, stateless endpoint, job_id return, polling frequency (~5s), and glyph prefix effect. No annotations provided, so description carries full burden; it covers essential behavioral traits but omits error handling or rate limits.

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?

Three sentences, each serving a purpose: main action, async instructions, alternative. No redundancy, well-structured and front-loaded.

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 two parameters, description explains async job, polling, alternative, and glyph prefixes. Lacks explanation of 'multi-voice deliberation' but overall sufficient for an agent to use 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%, baseline 3. Description adds meaning for 'query' by explaining 'Glyph prefixes (Ξ Ψ ∅ Ω ∞ Δ) modify how the engine thinks.' No additional info for syntheticIdentity, but overall adds value beyond schema.

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?

Description clearly states 'Submit a FULL multi-voice deliberation (~50s) against the corpus,' specifying verb, resource, and scope. It distinguishes from sibling omnarai_context by noting the difference.

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 says 'For fast context without deliberation, use omnarai_context instead,' providing a clear alternative. Also gives polling instructions with omnarai_job, guiding when and how to use the 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?

No annotations are provided, but the description discloses behavioral traits: async job, ~35s runtime, returns job_id, honest by construction. It does not mention destructive actions, authentication, or rate limits.

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 sentences, front-loaded with key purpose and behavioral detail. Every sentence adds value; no fluff.

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 simple input and no output schema, the description explains return values (delta and verdict) and async workflow. It references sibling tool for polling.

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% with one parameter 'question' having a clear description. The description adds minimal extra meaning beyond stating it answers the question twice.

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 measures baseline-vs-augmented counterfactual, answering a question twice and reporting delta and verdict. It distinguishes from siblings by specifying it runs as an async job returning a job_id.

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 mentions the async nature (~35s) and polling requirement, but does not explicitly state when to use this tool vs alternatives or when to avoid it.

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