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

The description discloses important behavioral details beyond the annotations: the total is NEGATIVE, the list is sorted newest first, and the amount credited per currency is included. Since the annotations are only false hints (readOnlyHint=false, destructiveHint=false) and do not provide a clear safety profile, the description carries the burden and does it well by highlighting the negative total and ordering behavior.

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 description is two sentences with zero fluff. The first sentence front-loads the action, resource, and key output details (including the critical negative total); the second sentence covers all filters. Every word earns its place, and the structure is scannable for an agent.

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 list tool with 4 optional parameters and no output schema, the description explains what will be returned (fields, ordering, negative total, per-currency amount) and the available filters. It lacks explicit mention of pagination or response format, but given the simplicity of the tool and that the schema covers parameters, this is sufficient. It is not fully exhaustive but is clearly above the minimum viable.

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 the baseline is 3. The description adds little beyond the schema: it mentions filters by invoice, client, or date range, which maps directly to the parameters, but does not add extra meaning or clarify value formats that the schema already provides. The 'amount credited per currency' is an output behavior, not parameter semantics.

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 states a specific verb and resource: 'List credit notes' and specifies the output fields (id, invoice, client, basis, reason, currency, NEGATIVE total) and filtering options. It distinguishes itself from siblings like credit_note_get by focusing on listing, and from credit_note_text/pdf by describing the structured list output.

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 usage through the filter options and the 'newest first' ordering, but it does not explicitly mention when to use this tool versus alternatives such as credit_note_get or credit_note_text. There are no exclusions or alternative routing, so the guidance is implied rather than explicit.

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