recurring_generated

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. It does disclose a genuinely useful trait — results are ordered newest first — but says nothing about pagination behavior (limit/cursor), what is returned when a schedule has issued nothing, or required auth on the schedule. For a read-only listing tool that is adequate but thin.

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?

Short and front-loaded, which is good, but the two sentences are largely redundant: "The invoices one schedule has actually issued" and "The documents produced by this schedule" restate the same idea. Terminology also drifts between "invoices" and "documents" for the same return objects, which costs a little clarity.

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?

There is no output schema and no annotations, so the description must carry more than it does. It conveys the concept and ordering of results but omits pagination semantics and any sense of what a returned document record contains, which matters for an agent that must decide whether to page or how to consume the result.

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% — the schema gives only titles and types for `recurring_id`, `limit`, and `cursor`. The phrase "one schedule" implies what `recurring_id` selects, but `limit` and `cursor` (paging) are not explained at all, and "newest first" only hints at ordering rather than the cursor's role.

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 resource and scope: the documents/invoices actually issued by one recurring schedule, with explicit ordering ("newest first"). It also states what the tool is not (the list of schedules themselves), so an agent can distinguish it from the schedule-listing tool without opening the schema.

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?

Explicitly contrasts with the alternative: "as opposed to `list_recurring_invoices`, which lists the schedules themselves" tells the agent when to pick this one. However, the referenced sibling name does not exist in the sibling list (the actual tool is `recurring_list`), and there is no guidance on paging or on cases where no documents have been generated.

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