Get Hardware Info

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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: 'when available' signals that some commands may be absent, so results can be partial or missing subsystems. It does not state that the call is read-only (implied), whether all four probes always run, or what happens on a system lacking lspci/lsusb. A modest but genuine contribution beyond a bare name.

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 compact fragment with the key content (the four probe commands) front-loaded and no filler. It is efficient, though the telegraphic phrasing reads more like a note than a self-contained specification.

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?

The tool is simple (no parameters) and has an output schema that documents return values, so the description needn't explain them. Still, for a no-annotation read tool it could have said whether results are aggregated across the four sources, how missing tools are represented, and that it performs no system modification. Adequate but with clear residual gaps.

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 tool takes zero parameters, so there is no parameter meaning for the description to add. Baseline 4 applies; the description correctly avoids claiming options that don't exist.

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 names the resource ('Hardware details') and lists the concrete sources (lscpu, lsusb, lspci, lsblk), which tells an agent what content to expect. However, it doesn't distinguish this from close siblings such as get_system_info, get_cpu_usage, or get_memory_info, so the agent must infer the boundary. The verb is nominal rather than active, leaving purpose only partially pinned down.

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?

There is no explicit guidance on when to call this versus get_system_info, get_cpu_usage, or get_memory_info, and no exclusions or prerequisites. The only implicit cue is that it is an inventory-style read of physical hardware. An agent must derive usage from the tool name alone.

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