Get test results

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the leading 'Read-only' partly repeats structured data. It does add one genuinely useful behavioral detail the annotations lack — the comma-separated multi-value syntax for the status filter — but says nothing about pagination despite a limit parameter, or about result ordering/volume.

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 short, front-loaded fragments with no filler; the resource and the filtering trick are both immediate. The leading 'Read-only' is slightly wasteful given annotations, but nothing else is padded.

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?

No output schema exists, so the description should carry return-value expectations; 'individual API test results' is a thin sketch of the payload. With an undocumented limit parameter and no pagination or shape guidance, it is adequate but leaves real gaps for a results-listing 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 only 33%; 'run' is documented in the schema while 'limit' and 'status' are not. The description partially compensates by showing the status value syntax ('failed,errored'), but limit remains undocumented in both places, so it neither fully compensates nor is redundant.

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: reads individual API test results belonging to a named run. This is distinct from get_run_report (aggregate) and list_findings (issue-level), though the description never names those siblings to make the distinction explicit.

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 filter hint ('filter to failures with status "failed,errored"') implies the main use case of narrowing to failures, but it never states when to prefer this tool over get_run_report, get_run, or list_findings, nor any exclusions.

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