List transactions

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

Well beyond the annotations, it discloses that data is live, explains cursor pagination semantics (pass nextCursor back as cursor), describes the shape of each returned row, and — most importantly — warns that the underlying web-app API is unofficial and requires a web session, with the exact remediation command if it is expired. That auth/expiry behavior is not derivable from annotations or schema.

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 front-loaded paragraph that leads with purpose, then filters, then pagination, then return shape, then auth caveat — a sensible priority order with no filler. It is dense and long, but nearly every clause carries operational information; the login-path sentence is the only part that feels environment-specific rather than tool-semantic.

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 13-parameter, no-output-schema tool, the description compensates by summarizing the returned row fields (amount, direction, account, category/split categories, vendor, sales tax, review status) and explaining pagination and auth failure handling. An agent can call this correctly and recover from the most likely failure mode without extra discovery.

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?

With 92% schema description coverage the schema already documents nearly every parameter (including enums for sort, detail, source). The description only restates the main filters and the cursor convention, and adds nothing about transactionIds, sort, detail, pageSize or businessId defaults. 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?

Opens with a specific verb+resource ("List and search the business's transactions") and immediately bounds the resource by enumerating what counts as a transaction: bank/card transactions, expenses, deposits, transfers, bill and invoice payments. This is far more precise than the bare tool name and lets an agent distinguish it from ledger or report tools.

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?

Gives explicit filter conditions (date range, description text, accountId, categoryIds, uncategorizedOnly) and points to wave_list_accounts for obtaining accountId and to wave_get_transaction/update/delete for follow-up on the returned IDs. It does not state when to prefer this over wave_list_ledger_transactions or wave_run_report, so the sibling differentiation is incomplete.

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