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

With no annotations, the description carries the full burden and does well: it states the answers derive from OPSIN-signed verdicts across all notebooks, never from a model, which tells the agent the results are authoritative and non-generative. It also discloses empty-result behavior (it says so and points to opsin_propose). What it omits is the response shape and whether the call is strictly read-only, but the key trust characteristic is explicit.

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 the verb and the question examples, then the provenance and fallback behavior. Dense but no filler; the phrase 'Ask the signed record whether a part of an agent works' is slightly convoluted but each clause adds 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?

The tool is simple (one parameter, no nested objects), and the description covers purpose, data provenance, and the no-match path. However, with no output schema and no annotations, it never hints at what an answer looks like (a verdict record? prose? list?), leaving the agent guessing about return values.

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 0% and the single 'q' parameter has no description, so the description must compensate. The quoted example queries partly do this by showing the expected granularity and phrasing of a question, but the description never states that the input is one free-text question capped at 200 characters, leaving format constraints 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 (ask) plus a concrete resource (the signed record / signed verdicts) and a clear subject: whether a part of an agent works. The quoted examples ('calculator', 'answer only', 'persona', 'step by step') make the domain tangible. It does not clearly differentiate itself from sibling opsin_verdict, and 'signed record' is domain jargon an agent must infer.

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?

'before you ship it' implies a pre-deployment check context, and the description states a fallback path (offers opsin_propose when nothing matches). However, there is no explicit when-not guidance and no contrast with the many sibling query tools such as opsin_verdict or opsin_read_prompt.

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