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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context: that the values are 'measured', 'never asserted', and computed 'live from the gateway's own audit records (CO 292)'. It also discloses the empty-history behavior honestly. This is a model example of annotation-plus-description synergy.

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?

Though dense, the description front-loads the core concept and then efficiently covers usage, empty history, and a motivational catchphrase. The repetition of the empty-history return value is a small blemish—'an empty history' is explained twice—but the structure is otherwise tight and motivating.

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 2-param, no-output-schema tool, the description thoroughly covers the main use case, the data source, the meaning of an empty result, and an example call. It could mention whether the output is a single object or array, but since there's no output schema, the `{ p50, p95, p99, sample_count }` shape is sufficient. The example `call federation_latency with arguments {}` is trivially helpful but not harmful.

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 description only needs to add semantics beyond the schema. The description explains that tool= filters by tool name and limit= widens/narrows the sample window, offering the non-obvious default (500) and cap (5000) hint implicitly through 'default 500, cap 5000' in the schema. The description's added value is the 'sample window' framing, which maps the params to the underlying intent. Slight deduction for redundancy with schema details.

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 leads with a specific verb+resource combination ('Reproducible latency — the MEASURED p50/p95/p99...computed live from the gateway's own audit records') and clearly distinguishes this from asserting/estimating latency. It's unmistakably about querying measured latency percentiles of tool executions, which differentiates it from any assert-based sibling tool.

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 explicit usage context: 'Omit args for whole surface; tool= to scope to one tool; limit= to widen/narrow the sample window.' It also covers the empty-history case and says to 're-call after traffic.' It doesn't name alternative sibling tools, but for a latency-measurement tool this is a clear contextual signal, though not an exhaustive exclusion list.

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