Node Latency Events

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description still adds real behavior beyond that: it discloses the two-stage command sequence, that HISTORY is capped at the 3 worst events, that findings are ordered first, and that a zero latency-monitor-threshold produces a named finding about missing data. What it does not say is whether an empty result means healthy or unconfigured.

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 short and front-loads 'findings first', but the telegraphic, comma-spliced phrasing (a command list with no main verb) forces the reader to reconstruct the sentence. Tightening into one declarative sentence would cost no information and remove ambiguity.

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-shape explanation is unnecessary, and a zero-parameter diagnostic needs little more than what is given: the command sequence, the cap of 3 events, the flagged conditions, and the zero-threshold caveat. The remaining gap is the relationship to node_latency, which leaves the agent guessing between two adjacent tools.

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 the schema baseline is 4. The description uses its space on command behavior rather than parameter meaning, which is acceptable here but means no additional semantic value is contributed beyond the empty schema.

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 underlying commands (LATENCY LATEST, then HISTORY for the 3 worst events) and the findings it surfaces (fork/aof-fsync over 100 ms, expire-cycle spikes, trimmed LATENCY/MEMORY DOCTOR), so the resource is identifiable. However, there is no verb stating what the tool does for the caller — it reads as an implementation note rather than a purpose statement — and nothing distinguishes it from the sibling node_latency.

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?

No when-to-use guidance and no alternatives are named, even though node_latency and node_triage are plausible siblings for latency investigation. The only conditional clause, 'With latency-monitor-threshold 0 the finding names it,' is a caveat about a finding, not a routing rule for the agent.

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