omniseek_curator_view

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it states 'Never mutates,' describes what each view returns, explains the error behavior for unknown 'what', and specifies the exact structure of the audit dossier (facts, ratios, safety flags, no verdict key). This is transparent about side effects and outputs.

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 well-organized with bold labels and bullet points, front-loading the key usage directive. Every sentence adds necessary detail, though some redundancy exists (e.g., repeating the server name). It is not excessively verbose but is longer than minimal; still, the structure makes it scannable.

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 (three views, multiple states, integration with another tool), the description is complete: it covers the entry point, output formats, error handling, and the follow-up action via omniseek_curator_act. Without an output schema, it explains what to expect for each view, leaving no critical gap for an agent to call it correctly.

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

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

The schema provides no parameter descriptions (0% coverage), so the description must define all parameters. It does so comprehensively: 'what' is explained with its three valid values and their meaning, 'state' is listed with its filter options for the queue view, and 'candidate_id' is tied to the packet view. Unknown values are also handled.

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 clear directive ('Use WHEN running the source-curation protocol') and names the specific resource (curator state) with three distinct views (queue, packet, audit). It also differentiates from the sibling action tool omniseek_curator_act, making the purpose unmistakable.

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 states when to use the tool (during curation protocol), and for each view it explains the scenario (e.g., 'list awaiting_verdict' for queue, 'last-built evidence packet' for packet, 'render KEEP / WATCH / PRUNE' via the act tool for audit). It also notes that unknown values return an error listing valid options, guiding correct use.

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