redis_latency_rca

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

Annotations only declare readOnlyHint=true, and the description goes well beyond that by naming the exact data sources it reads (SLOWLOG by command pattern, INFO stall signals like blocked clients, fork stalls, delayed AOF fsyncs, dataset loading). It even discloses that every finding carries its numbers. It doesn't mention rate limits or cost of the live pull, so not a full 5.

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?

Front-loads the one-line purpose and [READ] marker, then structures Args and Returns clearly with no filler. The paragraph enumerating stall signals is dense but each item earns its place as diagnostic content; total length is slightly long for a 3-param tool.

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?

No output schema exists, but the description summarizes the return dict structure (slowlogPatterns, patternsOverThreshold, thresholds, findings with cause/action/evidence, note), and with the readOnly annotation plus full arg docs an agent has everything needed to call and interpret this tool correctly.

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?

With schema coverage at 0%, the description carries the burden and does: it documents slow_us with its unit and default (10000 = 10ms), enumerates the telemetry object's keys and meaning, and explains target as 'a redis target name from config; omit for the default.' The only gap is the absence of types/units for the nested telemetry fields, but coverage is strong overall.

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?

States a specific verb+resource ('Diagnose redis latency') and enumerates exactly what it produces: slowlog digest by command pattern plus stall causes and actions. It is clearly distinguishable from siblings like redis_slowlog (raw slowlog) and redis_memory_pressure_rca (memory-focused).

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?

Gives explicit operational guidance: 'Pass telemetry for pure analysis, or a target to pull live,' which tells the agent both modes of invocation. It stops short of naming when to prefer this over redis_slowlog or the other RCA siblings, leaving that comparison to inference.

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