rp_system_diagnostics

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

The annotations already establish readOnly, idempotent, openWorld, and non-destructive behavior, so the description correctly reinforces "no writes" without contradicting them. It adds useful context that fixed-command SSH may be used, but does not explain SSH authentication requirements, command restrictions, or execution limits beyond that phrase.

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 definition is a single front-loaded sentence with no wasted language. "Read" comes first, followed by the evidence scope and the optional SSH behavior.

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 parameterless diagnostic tool whose annotations and output schema already cover safety and return structure, the description is largely complete. It could be stronger if it clarified what "fixed-command SSH" permits, but no critical invocation detail is missing.

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?

This tool has zero parameters, so parameter semantics have no room for additional description beyond the empty schema. The baseline for a no-parameter tool is therefore appropriate.

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 uses a specific verb, "Read," and names concrete evidence domains: OS, model, process, app, and FPGA. It is distinguishable from narrower siblings such as rp_device_diagnostics and rp_connection_status, though it does not explicitly contrast itself with them.

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 a read-only diagnostic collection task but never states when to use this tool instead of rp_device_diagnostics, rp_connection_probe, or other siblings. It also gives no exclusions or prerequisites for the optional SSH path.

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