list-bank-transactions

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

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses pagination behavior (10 items per page, requires calling again with next page number), user interaction requirements (ask about account filtering), and implies a read-only operation through 'List'. It doesn't mention rate limits, authentication needs, or error handling, but provides more than minimal disclosure.

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?

The description is verbose and poorly structured: it mixes tool functionality with user interaction instructions ('Ask the user...') and implementation details ('call this tool again...'). It's not front-loaded—the core purpose is buried among procedural steps. Multiple sentences could be condensed into clearer, more direct statements about the tool's behavior.

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, 0% schema coverage, and no output schema, the description provides moderate completeness: it covers purpose, usage context, and pagination behavior. However, it lacks details on return values (what data fields are included), error conditions, or comprehensive parameter documentation. For a list tool with 2 parameters, this is adequate but has clear gaps.

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 compensate. It mentions 'page' and 'bank account' parameters, explaining that 'page' is for pagination and 'bankAccountId' filters by account, which adds meaning beyond the bare schema. However, it doesn't explain parameter formats (e.g., what values 'page' accepts, what a valid 'bankAccountId' looks like), leaving significant gaps for 2 parameters with no schema documentation.

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 states the tool 'List all bank transactions in Xero' which provides a clear verb ('List') and resource ('bank transactions'), but it's vague about scope and doesn't distinguish from potential siblings like 'list-payments' or 'list-manual-journals' that might also involve financial transactions. It doesn't specify if this includes only cleared transactions, pending ones, or all types.

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 provides clear context on when to use it: 'Ask the user if they want to see bank transactions for a specific bank account, or to see all bank transactions before running.' This gives explicit guidance on user interaction and filtering options. However, it doesn't mention when NOT to use it or alternatives among sibling tools (e.g., vs. 'create-bank-transaction' or 'update-bank-transaction').

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