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

Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower, and the description far exceeds it: it discloses the recording start date (2026-09-20), the meaning of an empty result, the one-entry-per-day overwrite semantics, and that values are in the measure's own unit rather than money. These are non-obvious data-quality facts that materially affect interpretation.

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?

Four sentences, each carrying distinct meaning, with the list operation and ordering front-loaded. Slightly dense but no filler; the overwrite caveat and unit note both earn their place.

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?

For a read-only, zero-parameter-required list with a 100%-covered schema and no output schema, the description supplies the audit-relevant caveats (coverage start date, empty-list implication, same-day overwrite) an agent needs to interpret results correctly. No pagination-return detail is needed given automatic fetch-all behavior documented in the schema.

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 100%, so baseline is 3. The description adds only the purpose of los_measure_id ('Filter by measure ID'); it says nothing about page/per_page behavior, though the schema already documents those.

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 and resource ('List recorded changes to a LoS measure's target, minimum and stretch goal') and defines scope precisely. The sibling get_los_targets_history_entry returns a single entry; this description's 'One entry per measure per day' framing plus the list verb makes the distinction clear.

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 description implies when to use it (to see change history for a LoS measure) via the measure-ID filter and the newest-first ordering, but never states exclusions or names the singular sibling get_los_targets_history_entry. The audit caveat is useful but is behavioral, not routing guidance.

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