Skip to main content
Glama

xero_bank_transactions

Read-onlyIdempotent

Retrieve bank transactions from Xero for a specified date range and bank account to support reconciliation, reporting, and financial analysis.

Instructions

Get bank transactions from Xero.

Input Schema

NameRequiredDescriptionDefault
date_toNo
date_fromNo
tenant_idNo
access_tokenNo
bank_account_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds nothing beyond that: no pagination behavior, no default date range, no note on whether bank_account_id is required to get meaningful results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, but its brevity comes from omission rather than efficiency — nothing about parameters or scope is displaced elsewhere since there is no schema coverage or output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter, fully undocumented, zero-required-field tool with no output schema, the description should clarify which parameters to supply and what a call returns. It leaves the agent guessing about mandatory auth context and how to get a non-empty result set.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All five parameters have 0% schema description coverage and no required fields are declared, so the description must carry the burden of explaining them. It says nothing about date_from/date_to format or timezone, what tenant_id or access_token represent, or how bank_account_id narrows results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get bank transactions from Xero'), which the resource noun alone distinguishes from sibling xero_* tools like xero_invoices or xero_payments. It is clear but offers no explicit differentiation or scope statement (all transactions vs. a single account).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool, no mention of prerequisites such as tenant_id/access_token, and no indication of how it relates to alternatives like xero_reports or plaid_transactions. The agent must infer everything from the name.

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

Deploy Server

Other Tools