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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description productively enlarges on them: values are 'never asserted', 'computed live from real recorded call durations', and empty history produces an 'honest empty' rather than a fabricated number. This is exactly the right kind of disclosed uncertainty. Slight deduction for the redundant duplication of the empty-history caveat, which muddies otherwise strong transparency.

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?

Clearly front-loaded and the first sentences are excellent, but the back half falls apart into repetition: the phrase 'An empty history returns null percentiles + sample_count 0 (an honest empty, not a fabricated number) — re-call after traffic' appears almost verbatim twice (right after 'never asserted' and again in the Returns section), and the final 'Example: call federation_latency with arguments {}' is confusing filler. Every sentence should earn its place; two of them didn't.

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?

For a read-only introspection tool with zero required params, no output schema, and a small well-specified params set, this is largely complete: it covers the return shape { p50, p95, p99, sample_count }, the marginal-case behavior (empty history), and the data provenance ('CO 292' audit source). It doesn't really explain the distribution semantics behind p50/p95/p99, but nothing important is missing.

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% with descriptive text on both params ('Restrict the percentiles to one tool', 'Max recent samples to scan (default 500, cap 5000)'). The description layers on helpful semantic framing — 'tool= to scope to one tool; limit= to widen/narrow the sample window' — which adds a modicum of meaning, though it largely re-words the schema.

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+resource+scope: 'the MEASURED p50/p95/p99 (in ms) of recent authenticated tool executions, computed live from the gateway's own audit records.' The description crisply distinguishes this from siblings as the verifiable, measured source of truth for latency, and even positions it against the rival claim 'is it really sub-100ms?'. Purpose is unmistakable even before the title is read.

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?

Provides clear usage context: 'Omit args for the whole surface; tool= to scope to one tool; limit= to widen/narrow the sample window,' plus when to re-call ('re-call after traffic'). The 'verify, don't trust' heuristics signal intent. Loses a point for not naming explicit alternatives or stating when NOT to use this tool vs. a sibling — especially notable in a large federation_* namespace.

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