Lists recurring invoice schedules newest first so you can review account definitions, filter by status, and distinguish schedules from generated invoices.
The schedules on this account, newest first.
These are the recurring definitions, not the invoices they produce; for
those, use list_generated_invoices. Narrow with status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does add useful context — results are account-scoped, sorted newest first, and represent definitions rather than generated invoices — but it says nothing about pagination behavior, permissions, or total-count/ordering guarantees for a tool that clearly supports cursoring.
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?
Three short sentences, front-loaded with what the tool returns, followed by the disambiguation and the filtering hint. No filler and no repetition of the input schema.
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?
Given no annotations, no output schema, and zero parameter documentation, the description resolves the highest-risk ambiguity (definitions vs. generated invoices) competently. However, it leaves an agent guessing about cursor-based paging and what a schedule record looks like, which is a meaningful gap for a list endpoint.
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%, so the description must explain all three parameters. It only addresses `status` (results can be narrowed by it) and gives no semantics for `limit` or `cursor`, leaving the pagination contract entirely undocumented in both schema and description.
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 identifies the resource (recurring schedule definitions on this account) and the ordering (newest first), and it explicitly separates this from the invoices those schedules produce. The verb is implied by the tool name rather than stated, but an agent can still tell this apart from recurring_generated or the document_* siblings.
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?
It names the alternative explicitly ('for those, use `list_generated_invoices`') and states the distinguishing condition, which is the most likely point of confusion for this tool family. It also notes that results can be narrowed with `status`, though there is no guidance on when filtering is advisable or on how paging should proceed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.