Ask one yes/no question

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds genuinely new operational context: this is the cheapest call and marginal questions are nearly free once the model is loaded. That cost/latency framing is exactly the kind of trait annotations cannot express. It does not discuss caching behavior directly, though `use_cache` is documented in the schema.

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 short sentences, front-loaded with the tool's value proposition, then the phrasing rule, then the alternative. No filler, though the hard line breaks inside sentences make it slightly less scannable than it could be.

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?

An output schema exists, so return values need not be explained, and the description still previews the shape ('a calibrated yes/no and a directive'). For a five-parameter tool with full schema coverage and annotations, the remaining description content is sufficient; only the threshold semantics (deferred to `decide`) are left to the 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 description coverage is 100%, so the schema already documents all five parameters, including the meaning of `statement` and `state`. The description reinforces the phrasing convention for `statement` ('phrase positively, true = go ahead'), but that largely duplicates the schema's own wording, so baseline 3 is correct.

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 makes clear this tool evaluates a single statement and returns a calibrated yes/no plus a directive, and it explicitly contrasts that scope with the multi-question sibling `decide`. It stops short of a clean verb+resource phrasing (e.g. 'evaluate one statement'), but an agent can confidently distinguish it from the other 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?

It states the positive-phrasing convention and gives an explicit routing rule: 'Prefer `decide` when you have several questions, since extra questions cost almost nothing once the model is loaded.' That names the alternative and the condition that selects it, though it does not spell out when this tool should NOT be used.

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