list_conversionsList one cursor page of conversion jobs visible to the MainBook account. Pass the returned next_cursor to continue.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Jobs on this page, from 1 to 100. | |
| cursor | No | Opaque next_cursor from the previous page. |
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | ||
| units | No | pages | |
| conversions | Yes | ||
| next_cursor | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds that it returns only one page, uses a cursor for continuation, and scopes to 'MainBook account', which are useful behavioral details beyond what annotations convey. No contradictions.
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?
Two sentences with zero waste. The first sentence establishes purpose and scope, the second provides actionable usage guidance. Perfectly front-loaded and concise.
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 the tool is simple (two optional parameters, output schema exists), the description adequately covers pagination and account scope. It could mention error cases or empty result behavior, but overall is complete for effective use.
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 coverage is 100% with both parameters having clear descriptions in the schema. The description mentions 'next_cursor' but does not add new meaning beyond what the schema already provides. Baseline 3 is appropriate.
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 clearly states it lists 'one cursor page of conversion jobs visible to the MainBook account', using a specific verb ('list') and resource ('conversion jobs'). It distinguishes itself from sibling tools: get_conversion (single conversion) and convert_bank_statement (creation).
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 explicitly instructs to 'pass the returned next_cursor to continue', providing clear pagination usage. While it doesn't list when not to use or mention alternatives, the context of sibling tools makes this unnecessary for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: starting a conversion, checking credits, retrieving a specific conversion, and listing conversions. There is no overlap or ambiguity among the four tools.
All tool names follow a consistent verb_noun pattern: convert_bank_statement, get_balance, get_conversion, list_conversions. This makes the naming predictable and easy to reason about.
With exactly 4 tools, the set is well-scoped for a bank statement converter. Each tool covers an essential part of the workflow without unnecessary redundancy or bloat.
The tool surface covers the full lifecycle: initiating a conversion, checking credit balance, retrieving results, and listing past jobs. There are no significant gaps for the stated purpose of converting and retrieving bank statements.