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

Annotations declare write-but-not-destructive and non-open-world; the description adds real behavioral context beyond that: output is self-contained, writes are confined 'inside a root', and only the file path is returned. It stops short of explaining overwrite semantics or failure modes, but the sandboxing and return behavior are genuinely useful additions.

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 tight sentences with zero filler; the primary capability (formats) is front-loaded and the output_path side effect follows. Every clause carries 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?

With no output schema and five optional parameters, the description adequately covers the format choices and the file-writing path. It is slightly thin on the findings/findings_path input alternatives and overwrite behavior, but the core invocation path is well covered.

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 60%. The description usefully maps the format enum to human-readable outputs and clarifies output_path's write-and-return-path behavior, but it says nothing about findings vs findings_path, the overwrite flag, or the required-at-least-one-input constraint, leaving part of the parameter surface unexplained.

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 (render) and resource (findings into a dossier) plus the exact output formats (dark-mode HTML, GitHub SARIF 2.1.0, Markdown). This is clearly distinguishable from the sibling scan and verify_citations tools without opening any schema.

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

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

The description implies usage by explaining what happens when output_path is supplied, but never states when to choose this tool over its siblings or when each format is appropriate. No exclusions or alternatives are given, so usage must be inferred.

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, openWorldHint=false and idempotentHint, so 'offline and read-only' is largely redundant. The description nonetheless adds real behavioral context beyond them: deterministic execution, file:line evidence for every finding, and verification against the actual files.

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 compact sentences with the core capability front-loaded and no wasted clauses. The closing 'Offline and read-only' sentence partly restates what the annotations already provide, which is the only slack.

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 should carry more of the return-value burden. It does say findings cite file:line and are verified, but never explains the result shape, ordering, truncation relative to max_findings, or what 'verified' concretely means. Adequate but with clear gaps for a 4-param 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 only 25% (only 'path' is documented), so the description must compensate. It partially does by enumerating the four lens values that map to the undocumented 'lenses' parameter, but max_findings and min_severity/severity semantics remain undocumented in both places.

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+resource ('multi-lens scan ... of a local directory') with the four lenses enumerated, so the agent knows exactly what the tool does. It does not, however, distinguish itself from the siblings omniseek_verify_citations and omniseek_render_dossier, even though 'comes back verified' hints at overlap with the former.

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 scoping hints ('local directory', 'offline') imply when this is appropriate, but there is no explicit when-to-use, no exclusion, and no routing to omniseek_verify_citations or omniseek_render_dossier even though they sound adjacent. Usage is left largely 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 cover the safety profile (readOnly, idempotent, closed-world), and the description adds substantial behavior beyond that: what is verified against (working tree or a git ref), the return shape (a 0.0-1.0 grounding score), and the failure categories produced (drifted, hallucinated, invalid). Since there is no output schema, disclosing the score and flags here is genuinely necessary and valuable.

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 tight sentences: verification scope first, return values second, usage cue last. Every sentence carries distinct information and nothing is repeated.

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 and only a small optional-parameter surface, the description supplies exactly what an agent needs: what gets verified, what the result means, and when to reach for it. Nothing material is missing for correct invocation.

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 `ref`, `repo`, `findings` and `findings_path` are already documented, and the description largely restates them (git ref, findings document). The one added nuance is that findings may come from another model's output, which the schema does not say. Baseline 3 is appropriate when the schema carries the parameter burden.

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 (verify that each cited span/snippet/symbol in a findings document exists in the repo) and enumerates the exact citation kinds checked. This is clearly distinguishable from omniseek_scan (produces findings) and omniseek_render_dossier (renders them) without opening any schema.

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

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

"Use it on findings you or another model wrote" gives clear context for invocation, and the schema's reference to findings "as returned by omniseek_scan" chains it into the workflow. It stops short of naming an alternative or stating when not to use it (e.g. verifying against uncommitted work vs a ref), so it is not a full 5.

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