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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description reinforces that with 'Read' and 'Returns'. It adds behavioral value by explaining what data comes back (per-run/per-check verdicts), how to derive false-hold rate, and that free-text preview fields are tagged as data. No contradiction with annotations.

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 three sentences: purpose, return contents, and example questions. It is front-loaded and each sentence carries information. The 'Free-text preview fields are tagged as data' line is slightly cryptic but still earns its place as a data-format caution.

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 adequately describes the returned data (verdicts per run/check across specific gates) and the analytic use cases. It does not detail pagination or exact response structure, but the limit parameter is documented in schema and the return shape is clear enough for an agent to call and interpret the 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 coverage is 100%, so the baseline is 3. The description adds semantic richness beyond the schema by mapping human-readable gate labels (Pledge stamp, ICP consult) to the check_name enum values and explaining the verdict categories in context, which helps an agent pick correct filter values.

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 specific verb-resource pair ('Read recent quality-check telemetry') and scopes it to the current company. It names the exact verdict types and gate categories, making it unmistakably distinct from sibling tools like run_quality_check or get_activity_health.

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 provides concrete example questions ('which gate holds the most for this company', 'has the security gate ever fired on these posts') that signal when to use the tool. It does not explicitly name an alternative for running checks, but the read-vs-run distinction is strongly implied and clear.

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