Base rate of a single condition

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

The description significantly expands on the annotations (readOnlyHint=true, openWorldHint=true) by disclosing behavior around missing values ('never coerced to false or zero'), determinism ('Deterministic and free, including reruns'), error code expectations ('expect the 422 contract code verbatim'), and output echo. It also describes the output structure (base_rate_result.v1 fields), which is especially valuable given no output schema is present.

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 a single, well-structured paragraph of about 7 sentences, each delivering distinct value: purpose, output fields, exclusions, missing-data handling, guarantees, error behavior, and the echo. It is front-loaded with the core purpose and avoids redundancy with the schema.

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 fully compensates by listing the exact result fields (predicate_true_buckets, predicate_false_buckets, eligible_buckets, absent_or_ineligible_buckets, true prevalence) and global/per-symbol breakdown. It covers edge cases (missing values, grammar errors, determinism) and the echo behavior, making the tool's behavior completely understandable without needing to guess.

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%, so baseline is 3. The description adds meaningful parameter context beyond the schema by stating that 'field, operator and value must be grammar-valid (see list_features)' and warning about the 422 error code for invalid grammar. It also clarifies the meaning of 'eligible' buckets. These additions go beyond the schema's property descriptions, justifying a 4.

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 how often a single condition is true over eligible symbol-minute buckets, with a specific verb ('measure') and resource scope. It distinguishes itself from sibling tools by noting it is not a count of false-to-true episodes and computes no forward outcomes, differentiating it from tools like run_scan that may analyze outcome episodes.

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 gives clear context for use: 'SINGLE stated condition' and 'eligible symbol-minute buckets,' and explicitly says it is not for episode counts or forward outcomes. It does not name an alternative sibling directly, but the exclusions are strong enough to guide when not to use it, and it references list_features for grammar validation. However, it lacks an explicit 'use X instead' statement, so it doesn't quite reach a 5.

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