GPU smoke test

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, and the description is consistent with a job-submitting tool. It adds the useful resource-profile behavior, but omits the most important behavioral trait: that submission is gated behind a two-step dryRun(default true)+confirm flow, so the agent is not told the default call does NOT actually submit.

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 tight sentences: the first front-loads what the tool does, the second delivers the resource-selection rule. No filler, no redundancy.

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, and for a submit tool the description may reasonably omit return values. Combined with annotations that carry the safety profile and a schema covering the required project and the dryRun/confirm gating, the description supplies what the agent needs: purpose and resource targeting.

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 67%, so the baseline is 3. The description adds meaning for fullH100 and the default profile targeting, which the schema leaves blank, but it says nothing about dryRun, confirm, account, or profile interplay, so it only partially compensates for the uncovered parameters.

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 ('Submit a tiny GPU validation job') with the exact payload (nvidia-smi + torch CUDA check). It clearly separates itself from the many ris_submit_* siblings by being a validation job rather than real work, and from ris_gpu_status by being a submission, not a status 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?

The description explains the resource selection logic (MIG slice on general-short by default, full H100 on general-gpu when fullH100=true), which implies when the full-GPU variant is appropriate. However, it never states the scenario for using this tool versus a real submission (e.g. 'run before allocating GPU work'), nor does it surface the dryRun/confirm prerequisite workflow, leaving usage largely implicit.

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