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

readOnlyHint=true already tells the agent this is a safe read, so the description adds little beyond the 'active client' scoping and the vague word 'recent'. It says nothing about the default time window, result ordering, pagination, or why a read-only listing would expose confirm/dry_run/confirm_live flags — a genuinely confusing signal an agent needs resolved.

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?

One clean, front-loaded sentence with no filler, but here the brevity is under-specification rather than efficiency. The size is appropriate; the content is not.

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 values need not be described, but for a 34-parameter listing tool with zero schema coverage the description should at minimum explain the filter surface, the meaning of 'recent', and how to relate results to automate_confirm_action / automate_dismiss_action. None of that is present.

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 description coverage is 0% across 34 parameters, so the description carries the full burden and mostly fails it. Only 'active client' weakly maps to client_id; date_from/date_to, action, scope, rule_id, and the confirm/dry_run/confirm_live flags are entirely unexplained in both places.

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 gives a specific verb (List) and a specific resource (Kampalo pause proposals and executions) scoped to the active client, which distinguishes it from the mutation siblings automate_propose_pause and automate_confirm_action. It does not, however, differentiate itself from the several automate_list_* siblings, and it drops the 'budget' half of the title, so the inventory of what is listed is slightly inconsistent.

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 only usage cue is 'for the active client', which implies no client selector is needed. There is no statement of when to reach for this vs automate_list_automation_rules or the propose/confirm tools, and no guidance on the many optional filter parameters that clearly exist for narrowing the query.

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