monzo_list_transactions

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

With no annotations, the description carries full burden. It discloses caching behavior, auto-sync condition, and that it's not a live API call. This is sufficient for a read-only tool; no mention of auth or rate limits but acceptable given its non-destructive nature.

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 well-structured with a brief initial sentence followed by parameter details. It is slightly verbose with examples but overall efficient. The most critical info is front-loaded.

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 6 parameters, an output schema exists, and no nested objects, the description covers caching, sync, parameter semantics, and limitations. It is complete for typical usage; could mention pagination or error handling but not necessary.

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 description must add value. It explains each parameter: account_type values, since/before semantics with examples, category exact match with examples, merchant partial match, and limit default. This is highly informative beyond the raw schema.

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 the tool lists transactions from a local cache, distinguishing it from live API queries and siblings like monzo_search_transactions. The verb 'list' combined with 'from the local cache' provides a specific resource and scope.

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 explains it queries the synced database, not the live API, and mentions auto-sync when cache is stale. While it does not explicitly contrast with siblings like monzo_search_transactions, the context implies when to use this filtered listing versus a search. Could be improved with direct comparison.

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