List hosts

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld. The description adds genuine behavioral context beyond them: the server auto-refreshes caches older than a threshold, and a host absent from the cache reports 'unknown' rather than failing. It still doesn't say how stale the threshold is or whether 'unknown' is an error state.

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 short sentences, front-loaded with the resource and result, no filler. The second sentence is slightly compressed/awkward ('refreshes a cache older than the threshold itself') but earns its place by explaining status semantics.

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?

An output schema exists, so return-value detail is not required. The description covers the cache/status model that an agent needs to interpret results, though the threshold's origin and the refresh-flag interaction remain underspecified.

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 coverage is 100% and the single refresh parameter is documented in the schema, so the baseline is 3. The description's cache-refresh sentence is related but ambiguous about how it interacts with the explicit refresh flag.

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 concrete resource (~/.ssh/config hosts) and the information returned (last known availability), which is more than a restatement of the name. It does not explicitly distinguish itself from close siblings like check_hosts or get_host, so it stops short of a 5.

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?

Usage is implied by the resource and the 'last known availability' framing, but there is no explicit statement of when to call this versus check_hosts (live measurement) or get_host (single host). The agent must infer the routing.

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