list_invoices

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether the result is paginated, ordered, capped, or scoped to a workspace/company. It implies a read-only listing but never states it explicitly, nor does it mention any limits on the number of returned invoices.

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?

A single short sentence with no filler; the scope qualifier is placed at the end where it reads naturally. It is efficient but so terse that brevity shades into under-specification.

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 both optional parameters are fully documented in the schema, which covers most of the load for a simple list tool. However, with no annotations and no statement of default filtering, ordering, or result limits, an agent still cannot predict what it will get back for a bare call.

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% — month is documented as YYYY-MM and status explains issued = unpaid, paid = paid — so the baseline is 3. The description adds only a loose hint about overdue invoices and does not clarify the default behavior when month or status is omitted.

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?

"Vydané faktury z evidence" largely restates the tool name (list_invoices) as a noun phrase, and the only added information is the scope note that overdue invoices are included. It does not distinguish this from siblings such as get_invoice (single invoice) or sync_invoices, leaving the agent to infer that this is the bulk retrieval path.

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?

There is no guidance on when to use this versus get_invoice, sync_invoices, or export_book. The one contextual hint — that overdue invoices are included — is useful but describes scope, not when to choose this tool.

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