gpu_status

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It implies this is a read-only status check, but it does not mention potential requirements such as NVIDIA drivers or what happens if no GPU is available. It also does not describe the output format beyond the listed fields. For a simple status tool, this is adequate but lacks depth.

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?

The description is a single, concise sentence that front-loads the key information: it states the resource (NVIDIA GPU) and immediately lists the most important output fields (name, temperature, utilization, VRAM usage). There is no redundant or filler wording, making it appropriately sized and immediately informative.

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?

Since there is no output schema, the description should clarify the return structure. It lists the fields but does not specify whether the result is a single GPU, a list of GPUs, or how the text/json format affects the output. For a simple status tool, this is adequate but leaves some ambiguity about the exact response format.

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?

The only parameter, 'format', is fully described in the schema with an enum (text/json), a default value, and a clear description 'Output format', giving 100% schema coverage. The tool description does not add any extra parametric context, but since the schema fully explains the parameter, the baseline of 3 applies.

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 clearly identifies the tool as retrieving NVIDIA GPU status and lists specific metrics such as name, temperature, utilization, and VRAM usage. This makes it easy to distinguish from sibling tools like gpu_processes, which focuses on processes, and system_overview, which is broader. Although the description is a noun phrase rather than an explicit verb, the tool name 'gpu_status' implies a status retrieval action.

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 implies the tool is for checking GPU status, which is a reasonable inference, but it does not provide explicit guidance on when to use it over alternatives. There is no mention of related tools like gpu_processes for per-process GPU activity or when not to use this tool. The usage context is implied rather than stated.

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