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

Annotations already cover read-only, idempotent, non-destructive, so the description spends its words on what actually matters: sorting by total time across all hits, units in milliseconds, and that results are paginated with a totalUrls field to detect truncation. Minor blemish: it refers to 'urlOffset' while the parameter is named 'offset', which could momentarily confuse an agent.

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?

Two dense sentences: purpose plus returned fields first, then the sibling relationship and the paging check. Every clause earns its place, though the metric enumeration is long and the trailing 'page on with offset' clause is slightly redundant with the offset parameter description.

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 the description needn't enumerate return structure exhaustively, yet it still names the metrics and the totalUrls field used to judge completeness. Combined with the pagination guidance and the finished-test precondition, an agent has everything needed to invoke and interpret this tool correctly.

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 75% (limit, offset, loadTestId documented; projectId bare), so the description adds genuine value: it explains offset-based paging against totalUrls and that ordering is by total time, which tells the agent how offset interacts with the result set. It does not restate the default-20/max-100 bounds, but the schema already does.

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?

States a specific verb and resource (response times per URL for a finished load test) plus the sort order and the exact metrics returned. It is clearly distinguishable from the report/percentile sibling because it names that sibling and positions itself as the drill-down view.

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?

Explicitly says 'Use it to name the slow pages behind the percentiles in get_load_test_report', which routes the agent to this tool after reading a report. The 'finished Load Test' qualifier implicitly excludes in-progress tests, but no alternative is named for that case (e.g. get_load_test_status).

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