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

With no annotations, the description carries the behavioral disclosure burden. It usefully discloses return fields and a side effect: 'Also records a balance snapshot.' However, it omits details about authorization, whether the balance is live/cached, or consequences of the snapshot, leaving material ambiguity for a side-effecting read tool.

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 compact, front-loaded with the core action, and structured into Args and Returns sections. Every sentence earns its place and there is no filler.

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 single-parameter tool with an output schema, the description is mostly sufficient to invoke correctly. It covers the parameter, the return, and a side effect. However, it lacks usage context and enough detail about the snapshot side effect to feel fully complete.

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?

The description restates the only parameter and its allowed values, which are already present in the schema as an enum with a default. It provides no deeper meaning about what distinguishes personal from joint or how selection works, so it only partially compensates for the absence of schema descriptions.

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 a specific verb and resource: 'Get current balance for a Monzo account.' This clearly distinguishes it from siblings like monzo_list_transactions, monzo_list_accounts, and monzo_spending.

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?

No when-to-use or when-not-to-use guidance is provided. It mentions the account_type default but does not explain how to choose between personal and joint, nor does it point to an alternative sibling for cases where a different tool would be more appropriate.

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

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

No annotations present. The description states it returns account details, but does not explicitly confirm it is read-only or disclose potential side effects. For a simple list, default behavior is assumed.

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, no wasted words, front-loaded with purpose and key return details.

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 zero-parameter list tool with an output schema, the description sufficiently explains what is returned (type and status), making it complete.

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?

Zero parameters: schema coverage is 100% trivially, and the description adds no param info (as none needed). Baseline of 4 is appropriate per rubric.

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?

Description clearly states verb 'List' and resource 'Monzo accounts', specifying returned details (type, status) that distinguish it from siblings like transaction or balance 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?

No explicit when-to-use or alternatives are provided. Usage is implied from context, but the description lacks direct guidance.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses what the tool returns (account, pot names, balances) and notes an important side effect: "Also records balance snapshots." It does not discuss authentication or rate limits, but for a simple list tool the disclosure is adequate.

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 compact and well-structured: purpose comes first, followed by the single argument, then return behavior and side effect. Every sentence earns its place and there is no extraneous content.

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 tool with one optional parameter and an output schema, the description covers purpose, argument semantics, return contents, and the snapshot side effect. Nothing an agent needs to invoke it correctly is missing.

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?

The description restates the schema's enum and default values for account_type without adding deeper meaning, such as when to choose personal versus joint. Since it is the only optional parameter and the schema already defines it clearly, this is sufficient but not additive.

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 a specific verb and resource: "List all pots (savings buckets) for a Monzo account." This clearly distinguishes the tool from the sibling tools, none of which target pots, and the parenthetical clarifies the domain-specific term.

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 gives clear context on what the tool does and documents the account_type choice of personal or joint. It does not explicitly name alternatives or exclusions, but no sibling tool overlaps with listing pots, so the guidance is sufficient for selection.

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

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

With no annotations present, the description carries the full burden, and it discloses the most important behaviors: cached-not-live data access, the auto-sync side effect with its staleness threshold, the counterparty enrichment for bank transfers, and the shape of the response envelope. It stops short of a 5 because it does not state what happens if the auto-sync fails (stale data served? error?) or whether results are paginated beyond the limit.

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 dense but well-organized: purpose front-loaded in the first line, followed by the cache/sync behavior, the counterparty caveat, the return envelope, and a clean Args block. Every sentence earns its place, and the parameter documentation is scannable rather than prose-heavy.

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 that an output schema exists, the description is not obligated to explain return values in detail, yet it still provides the top-level envelope. All six optional parameters are fully documented, and the tool's complexity is moderate. The only material gap is failure behavior during the auto-sync path and the absence of pagination semantics, which keeps this from a 5.

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 0%, so the description must document the parameters itself — and it does, exhaustively and with added meaning. It specifies inclusive/exclusive semantics for since/before, exact-match semantics for category, case-insensitive partial-match semantics for merchant, allowed values plus default for account_type, and the max-results behavior for limit, all with concrete examples. This fully compensates for the empty schema descriptions.

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 first line — 'List transactions from the local cache' — pairs a specific verb (list) with a specific resource (transactions) and a scope qualifier (local cache), immediately distinguishing it from siblings such as monzo_get_balance, monzo_list_pots, and monzo_search_transactions. The follow-up 'not the live API' further sharpens the boundary, making the tool's identity unambiguous.

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 gives clear context for when the tool is appropriate: it reads from the synced database rather than the live API, and it 'auto-syncs if the cache is stale (last sync before today)', which tells an agent when a prior sync step is unnecessary. It does not explicitly name an alternative tool for cases where live or search-level data is required (e.g., monzo_sync or monzo_search_transactions), so the when-not guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses case-insensitive partial matching, the exact fields searched, counterparty behavior for bank transfers, cache auto-sync behavior, and the response shape. This is unusually transparent for a search tool.

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 purpose is front-loaded in the first sentence, followed by compact, high-value behavioral details and a clean Args list. Every sentence adds information; there is no redundant filler.

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 tool with five parameters and no annotations, the description covers search matching, cache staleness behavior, date-range semantics, account filtering, result limits, and the returned JSON shape. Nothing essential is missing for an agent to select and invoke it correctly.

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?

The input schema has 0% description coverage, but the description lists every parameter with meaningful detail: query semantics, account_type values, since/before inclusivity with examples, and the limit default. This fully compensates for the schema gap.

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 pair: 'Search cached transactions by merchant, counterparty (payee), description, or notes.' This clearly distinguishes it from sibling tools like monzo_list_transactions or monzo_sync by focusing on search across cached transaction fields.

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 clear usage context: search by named fields, with automatic sync when the cache is stale ('last sync before today'). It stops short of explicitly naming alternatives or saying when not to use the tool, but the intended scenarios are easy to infer.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the auto-sync side effect, the output behavior (account_type echo, null when unfiltered), and the detail switch affecting the return format. This goes beyond the schema and provides useful context, though it does not mention potential side effects like rate limits or error handling. The disclosure is substantial and does not contradict any annotations.

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: a clear summary sentence, a brief note on caching, an explanation of output behavior, and a concise Args list. It is front-loaded with the core purpose, and every sentence adds value. It is appropriately sized for a tool with four parameters and behavioral nuances, with no redundant phrasing.

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?

The description covers the tool's purpose, caching behavior, output characteristics, and all parameter semantics. It does not explicitly detail the return schema, but an output schema is available, so that is acceptable. It lacks explicit guidance on when to use this versus siblings, but the purpose is clear enough. Overall, it is nearly complete for an analysis tool, with only minor 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. The Args section provides format (YYYY-MM for month), examples (category values), default behavior (current month, all accounts), and the effect of detail (individual transactions vs summary). This adds rich meaning beyond the bare schema titles and types, fully satisfying the requirement.

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 opens with 'Analyse spending from cached Monzo transactions,' which states a specific verb (analyse), a resource (spending from Monzo transactions), and the caching behavior. This clearly distinguishes it from siblings like monzo_list_transactions (which would list raw transactions) and monzo_get_balance (which reads a balance). The purpose is unambiguous.

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 what the tool does and mentions auto-sync when the cache is stale, but it does not explicitly state when to prefer this tool over alternatives like monzo_search_transactions or monzo_list_transactions. The usage context is implied by the purpose (spending analysis) but not directly contrasted with siblings, leaving some room for ambiguity.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently covers the 11-month fetch window, the fallback to last-synced timestamp or 90 days, automatic pagination, auth-hold deduplication, and the SCA constraint on deep backfills. It does not address side effects on the local cache or auth prerequisites in detail, but it is substantially transparent.

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 purpose statement, a behavior summary, and a clear parameter list. Every sentence adds substantive value, and the most important constraints are front-loaded. There is no redundant restatement of schema information.

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?

The description is complete for a tool with two optional parameters and an output schema. It explains what the tool fetches, the sync window behavior, pagination/deduplication, parameter semantics, and edge cases around the SCA window. Return values are reasonably covered by the output schema, so no extra explanation is needed.

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, and it does. It explains account_type values ('personal', 'joint', or None to sync all accounts') and gives precise since formats (ISO date or datetime) plus its override behavior and SCA limitation. This goes well beyond the bare 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 states a specific verb ('Sync') and resource ('transactions, balances, and pots from the Monzo API into the local cache'), clearly distinguishing it from sibling read/list/search tools. It also adds concrete scope details like history depth, pagination, and deduplication.

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 implies usage for refreshing or backfilling a local cache, but it does not explicitly state when to prefer this over sibling tools like monzo_list_transactions or monzo_search_transactions. It gives helpful context around backfill windows and last-sync resumption, but no exclusions or alternative routing.

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