check_high_load

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions the host_name parameter comes from 'SSH_HOSTS config' implying SSH-based remote execution, and states the return includes 'top resource consumers and system load details.' It does not disclose read-only status, potential side effects, or performance implications, but for a diagnostic read-only tool this is minimally adequate.

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 very concise and well-structured in two short sections: a one-sentence purpose statement and a minimal Args/Returns overview. Every sentence adds value; there is no fluff or repetition.

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?

This is a simple one-parameter diagnostic tool with an output schema present. The description covers the parameter and gives a high-level summary of the return ('Top resource consumers and system load details'). It does not explain output format, but the existence of an output schema relieves the description of that burden. It could mention the SSH connection context more explicitly, but the parenthetical reference to SSH_HOSTS is sufficient.

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 schema provides a nullable string with a default of null, but no description. The tool's description compensates by explaining the parameter's meaning: 'Named host from SSH_HOSTS config; uses default host if omitted.' This adds clear semantic value beyond the schema for the single parameter.

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 states the tool's function: 'Diagnose high CPU/memory load and identify resource hogs.' This is a specific verb ('diagnose') and resource ('high CPU/memory load') that distinguishes it from sibling tools like get_cpu_info or list_processes, though it does not explicitly name any alternative.

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 usage context is implied by the phrase 'Diagnose high CPU/memory load' – it should be used when load is suspected. However, there is no explicit guidance on when to use this tool instead of related tools (e.g., get_system_overview, list_processes) or any exclusions.

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