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

The annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description usefully goes beyond them by disclosing the currency (BRL) and the sign convention — positive = money out, while refunds, card payments, and deposits are reported separately as credits — which is non-obvious domain context an agent needs to interpret results.

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 tight sentences: the first front-loads what the tool does, the second adds the interpretation rules for amounts. Nothing is redundant and every clause carries information an agent would otherwise have to guess.

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?

With no output schema and a read-only annotation set, the description compensates well by explaining currency and sign semantics. The remaining gap is that it never sketches the return shape (ranked deltas? per-category breakdown?), which is the main thing an agent must infer.

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 100%: month_a/month_b are documented as earlier/later YYYY-MM and bank as an optional nubank/itau filter, so the schema does the heavy lifting. The description adds no parameter-level detail (format, ordering constraints, or default behavior when bank is omitted) beyond what the schema already states, matching the baseline 3.

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 names a specific verb (compare), resource (spending by category), and scope (two calendar months, highlighting what changed most), so the function is unambiguous. It does not explicitly name or contrast itself with siblings like monthly_totals or spending_summary, so it lands just short of the top mark.

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?

Usage is implied by the comparison framing — an agent can infer it applies when two months must be compared — but there is no explicit when-to-use/when-not-to-use statement and no mention of when to prefer spending_summary or monthly_totals instead. Prerequisites (e.g., whether month_b must follow month_a) are only implied.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the description's added value is the amount semantics: BRL currency, positive = money leaving the account, and refunds/card payments/deposits reported separately as credits. That sign convention is genuinely non-obvious context. It stops short of describing result shape or how partial matches are handled.

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?

Three dense sentences, front-loaded with the detection rule before the caveat and the sign/currency note. Every clause carries information an agent cannot get from the schema or annotations.

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?

With no output schema, the description does the heavy lifting on what counts as a match and how amounts are signed, which is the essential context. It omits what a returned result contains and whether near-misses are surfaced, but nothing critical to invoking the tool 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?

Schema description coverage is 100%, so both parameters (bank, min_months) are already documented and the baseline is 3. The description reinforces the cadence semantics ('about once a month', 'in several different months') that contextualize min_months and adds the 5% amount tolerance, but adds no syntax or format detail beyond the 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?

States a specific verb and resource ('detect likely subscriptions') and then defines the exact heuristic: same merchant, amount within 5%, roughly monthly, across several months. That precision clearly separates it from siblings like spending_summary or search_transactions, which do not infer recurrence.

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 when the tool is appropriate (identifying subscriptions) and gives one exclusion (installment purchases are ignored), but never names an alternative sibling or states when to prefer raw transaction search instead. Usage must be inferred from the purpose.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: unsupported banks are not errored but silently reported as skipped via list_invoices, which tells the agent what happens to bad input — useful beyond the structured fields.

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 short sentences, front-loaded with what is returned and followed by the one caveat that matters. No filler, nothing that could be cut without losing meaning.

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?

No output schema exists, so the description carries the return-value burden, and 'which banks and file formats' adequately conveys the shape. It is complete enough for such a simple, annotation-protected read, with only minor room to describe the format of the listing.

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 tool takes zero parameters, so per the rubric the baseline is 4. The description does not need to explain inputs, and it correctly frames the call as argument-free discovery.

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 resource precisely — the banks and file formats the server can read — and the name/title reinforce it. It does not use an explicit verb, but it distinguishes itself from siblings by referencing list_invoices' skip behavior, so an agent can tell it apart from the transaction-oriented 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?

Usage is only implied: you call it to discover what input is acceptable, and the note that unsupported files are 'skipped by list_invoices' hints at the downstream consequence. There is no explicit 'use this before X' or when-not-to-use guidance, so the agent must infer the trigger.

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?

Annotations already declare this is a safe, idempotent, read-only, closed-world operation, yet the description adds substantial non-obvious behavior: the `check` reconciliation flag, the skippedFiles bucket for unreadable files, BRL currency, and the sign convention that positive amounts are debits while refunds/payments/deposits are credits. These semantics are exactly what an agent needs to interpret results and cannot be inferred from the 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?

Three dense sentences, front-loaded with the core purpose, with no filler or redundancy. It is information-rich rather than bloated, though the sign-convention sentence is long and could be split for scannability.

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?

With no output schema, the description correctly takes on responsibility for return-value semantics (fields, currency, credits vs debits, skippedFiles) and does so well. It omits the optional bank filter and any notion of ordering, pagination, or result size, which leaves a small gap for a listing tool.

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 100% and the single `bank` enum parameter is fully documented by the schema itself. The description mentions 'bank' only as a returned attribute and never explains the filtering behavior, so it adds nothing over the schema. Baseline 3 is appropriate when the schema carries the load.

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?

States a clear verb+resource ('List the invoice files') and enumerates exactly what each entry contains (bank, month, type, due date, transaction count, spend), which is specific enough to separate it from siblings like spending_summary or monthly_totals. It stops short of naming an alternative, so it doesn't quite reach the 5 level.

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?

There is no explicit when-to-use or when-not-to-use guidance. Nothing tells the agent why it would call list_invoices rather than search_transactions or monthly_totals, and no preconditions or exclusions are stated. Usage is only inferable from the returned fields.

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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds substantive semantics beyond the annotations: months are derived from transaction dates, amounts are in BRL, and a positive amount means money leaving the account while refunds/payments/deposits appear separately as credits. That sign convention is a real behavioral detail an agent could not otherwise infer.

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?

Four short sentences, each carrying distinct information; the core output semantics (what is counted and how it is signed) are front-loaded before the secondary currency and credit notes.

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?

With no output schema, the description carries the burden of explaining returns, and it does: it defines the two reported quantities, the currency, the sign convention, and where credits land. For a two-optional-param aggregation tool, nothing essential 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?

Schema coverage is 50%: bank is fully documented with its enum in the schema, while category has no description in either place. The description clarifies that these are optional scoping filters ('optionally for one bank or category'), but does not explain how category matches or how multiple values combine, so it only partially compensates for the 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?

The description names the resource (spend and credits) and its grouping (per calendar month), which is specific enough to distinguish it from a raw listing. It does not explicitly contrast with the closest siblings such as spending_summary or compare_months, so an agent must infer the boundary.

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?

It states that bank and category are optional narrowing filters, implying usage, but never says when to choose this over spending_summary or compare_months, nor when it would be inappropriate. Usage is implied rather than guided.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: results are ordered newest first, amounts are normalized to absolute BRL, and the sign convention is documented along with the fact that refunds/card payments/deposits are reported separately as credits. It does not mention the default row cap or the absence of pagination.

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?

Three tight sentences with zero filler; the searchable dimensions and ordering come first, followed by the amount semantics that most need emphasis. Every sentence adds information an agent would otherwise have to guess.

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 read-only, no-required-parameter search tool with no output schema, the description covers the essentials: what can be filtered, ordering, currency, and sign semantics. The remaining holes are the unexplained `invoice` parameter and no statement about row limits relative to the 200 max, which matter because limit is the only way to bound a broad query.

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 only 33%, so the description must carry weight, and it does for the highest-risk parameters: min_amount/max_amount compare the absolute value, and the sign of a returned amount carries meaning (positive = money out). This prevents systematic misinterpretation of spend vs. credit. Gaps remain: the `invoice` parameter is undocumented in both schema and description, and the from/to date format is never stated.

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?

States a specific verb and resource ('Find individual transactions') plus the full set of filter dimensions and the result ordering. The word 'individual' implicitly contrasts with the aggregate siblings (spending_summary, monthly_totals, compare_months, find_recurring_charges), so an agent can pick the row-level tool without inspecting a schema.

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?

Usage is implied by listing the filterable dimensions, so an agent knows this is the search/filter entry point. However, it names no alternative and gives no when-not condition — e.g. it never says to prefer spending_summary or monthly_totals for totals rather than enumerating rows.

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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious semantics: amounts are in BRL, positive values represent outflows, and refunds/card payments/deposits are reported separately as credits — critical for interpreting results correctly.

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?

Three sentences, tightly front-loaded with capability first and the sign/currency convention last. Every sentence carries information, though the opening noun-list fragment is dense without a lead verb.

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?

With no output schema, the description usefully enumerates the returned aggregations, and the sign convention covers the biggest interpretation risk. It omits how many merchants/purchases are returned and what the default date range is when from/to are omitted, both of which remain unknown to the agent.

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 100%, so both the filters and their formats (date pattern, bank enum, invoice id example) are already documented in the schema. The description restates the filter set but adds no syntax or default-value detail beyond it, making 3 the correct baseline.

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 names specific outputs (totals, spend by bank and category, top merchants, largest purchases), which is a clear verb+resource statement an agent can act on. It does not, however, differentiate itself from siblings like monthly_totals or compare_months, which cover overlapping analytic ground.

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?

It states the available narrowing dimensions ('Optionally narrow by bank, invoice, date range or category'), which implies when the filters apply, but never says when to choose this tool over monthly_totals, compare_months or search_transactions. Usage is inferable but not routed.

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