query_triton_autotune_selections

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: results arrive as a single cursor-bounded page (not a full dump) and come from 'provider-reported' data. It stops short of explaining pagination mechanics like how to fetch the next page or whether a null cursor ends iteration, leaving a small gap.

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?

A single nine-word sentence with zero filler. The verb is front-loaded, the resource follows immediately, and the pagination constraint is packed efficiently. Every word earns its place — this is concise without being underspecified.

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 simple read-only tool with a strong annotation profile and an output schema present, the description covers the core: what is returned and from where. However, it lacks workflow context (when Triton autotune selections are relevant, how they relate to a run) and gives no hint of run_id semantics. These gaps matter given no sibling routing and 0% parameter documentation.

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 description coverage is 0%, so the description carries the full burden for explaining parameters. It only weakly implies cursor's role via 'cursor-bounded page'; run_id is never explained (which run? a run of what?), and limit is only inferred from the word 'page'. The names, types, and constraints in the schema do most of the remaining work, which is not enough at this coverage level.

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 states a specific verb ('Return'), a distinct resource ('provider-reported Triton autotune selections'), and a scope qualifier ('one cursor-bounded page'). It is clearly not a tautology and the resource is specific enough to be tellable apart from siblings like query_measurements or query_static_candidates, though it does not explicitly name a differentiating sibling.

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 no guidance on when to use this tool versus alternatives. With dozens of sibling query/extract tools, there is no stated condition, prerequisite, or exclusion to help an agent decide between this and, say, query_measurements or extract_benchmark_samples.

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