List purchase transactions

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds the non-obvious default behavior (`unbatched:true`) and the fact that filters replace Moneybird's defaults entirely, which is critical behavioral context beyond what annotations convey. It could go to 5 with explicit return-format or pagination disclosure, but the default-behavior disclosure is strong.

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: first defines the resource, second discloses a hidden default and a specific call instruction. Front-loaded purpose, no filler, every sentence earns its place.

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 read-only list tool with full schema coverage, annotations carrying safety, and idempotency, the description is nearly sufficient. It doesn't describe pagination or return shape, but with no output schema, that's still a minor gap—most of what an agent needs to call it correctly is present.

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%, and every parameter has a description. The tool description adds context about the `filter` parameter's functional role (replacing defaults, the unbatched default). The description doesn't repeat schema details, which is proper. A 4 is appropriate because the description enriches the parameter semantics without needing to compensate for missing schema coverage.

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 verb (list) and resource (outgoing payment instructions / purchase transactions), and the first sentence clearly differentiates this tool from siblings like list_purchase_invoices and list_financial_mutations. The description even includes the domain-specific Moneybird term 'purchase transactions' and explains the batch distinction.

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 tells the agent about Moneybird's default `unbatched:true` and instructs it to pass an explicit filter to see batched transactions. It doesn't explicitly name sibling alternatives, but the context signals show many sibling list tools; the behavioral note about batching provides clear usage context. It could improve by saying 'use get_purchase_transaction for a single purchase transaction', but the guidance given is valuable.

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