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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the 'Read-only — never changes accounting data' sentence largely restates structured data. The genuinely additive part is the bounded scope ('last few' runs) and the disclosure of what diagnostics are surfaced, but no auth, freshness/latency, or error-retrieval limits are described.

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 compact sentences: the first front-loads what is returned, the second gives the caller's trigger phrase and the safety profile. No filler, no repetition of the title.

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 and the tool has no inputs, so completeness is easy to achieve and this description covers it. The only softness is the vague 'last few' — the exact window or cap on runs returned is never stated, leaving the agent unsure how far back the diagnostics reach.

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 there is nothing for the description to disambiguate and the schema is trivially complete. Baseline 4 applies; no parameter-level meaning is missing.

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?

Names a specific resource (Tally Prime sync runs) and enumerates exactly what is reported: timestamps, what was pushed, voucher create/alter counts, and Tally-side errors. An agent immediately knows the payload shape. It does not, however, distinguish itself from the sibling get_sync_status, which plausibly overlaps.

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?

Provides a concrete natural-language trigger ('my Tally sync failed'), which is a clear usage context. It stops short of exclusions or naming an alternative (e.g., when to prefer get_sync_status instead), so routing between the two sync tools is left to inference.

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