BankBridge

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

Beyond the readOnlyHint/idempotent annotations, it discloses the non-obvious two-step behavior: the tool only returns links and the actual connection occurs out-of-band when the user signs in to their bank in a browser. The explicit 'nothing is connected or changed by calling it' removes the main ambiguity an agent would have about a tool named 'connect_bank'.

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, front-loaded with the capability before the behavioral caveat. The final clause slightly restates the preceding sentence ('only returns links' vs 'nothing is connected or changed'), a small redundancy but not enough to obscure the message.

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 tool with no output schema, the description supplies the essential return semantics (links) and the follow-up action (user opens link at bankbridge.money). An agent has everything needed to decide to call it and to instruct the user correctly afterward.

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 the baseline is 4; there is no parameter semantics to explain and the description correctly avoids inventing any. Nothing about the call signature is left unclear.

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: it returns a link for connecting a new bank account plus reconnect links for banks needing re-authorization or expiring within 30 days. This clearly distinguishes it from the read-only siblings (list_accounts, get_account, search_transactions), none of which produce connection links.

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 concrete conditions for use: a new bank connection, a bank needing re-authorization, or consent expiring within 30 days. It does not name an alternative tool or state exclusions, but no sibling offers overlapping functionality, so the routing is unambiguous in practice.

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/openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond that: results are 'live', and the response can be partial, carrying a `warnings` array with per-bank messages and a reconnect_url — a detail that changes how an agent should interpret and act on the output.

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, zero filler. The core action and scope lead, and the response-shape sentence follows because no output schema exists to carry it.

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 one required parameter, rich annotations, and no output schema, the description does the necessary lifting by outlining the returned fields and the warnings/reconnect mechanism. The remaining gap is error semantics — what happens when the account_id is unknown or stale — which is not addressed.

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 account_id parameter is already documented with an example in the schema. The description only restates the provenance ('by its account id from list_accounts'), adding no new format or validation 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?

Specific verb ('Get') plus a precisely scoped resource ('one account's live details') with the returned fields enumerated (balances, credit limit, type, institution, last 4 digits). It also names the source of the identifier ('from list_accounts'), which cleanly separates it from the list_accounts sibling.

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 establishes the prerequisite workflow by stating the account id comes from list_accounts, so an agent knows to enumerate first and then fetch details. It does not state exclusions or compare against sibling alternatives (e.g. list_holdings for investment data), but none of the siblings is a real substitute for single-account detail.

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, openWorld, and non-destructive behavior. The description adds substantial context beyond that: case-insensitive substring matching, a 12-month default window, pagination defaults and caps, the fact that totals cover all matches even when transactions are paginated, and a warnings array for banks that could not contribute, including reconnect_url.

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 front-loaded with purpose and packed with useful details; every sentence contributes. It is a single dense paragraph rather than clearly structured bullets, which is a minor readability cost but not wasteful.

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 return-value burden and does so: it names the aggregate fields, explains transaction ordering (newest first), clarifies pagination vs. totals, and documents the warnings array. That is complete enough for an agent to call this tool 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: merchant matching is a case-insensitive substring against merchant name or description, the default window is the last 12 months, and limit/offset defaults and maximums are consolidated. It does not document account_id or exact start/end semantics 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 resource ('charge history for one merchant') and enumerates the aggregate fields returned, so the agent knows exactly what this tool produces. It does not explicitly contrast itself with siblings like search_transactions or get_recurring_charges, which keeps it from a 5.

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: this is the tool for merchant-specific charge history, and the default 12-month window is stated. However, there is no explicit guidance on when to choose it over search_transactions or get_recurring_charges, and no exclusions are given.

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?

Goes well beyond the annotations by disclosing exclusion rules (pending transactions omitted), the sign convention for income vs expenses, and partial-failure behavior via the `warnings` array with reconnect_url for banks that could not contribute. That partial-data disclosure is genuinely valuable for a read tool whose correctness depends on bank connectivity; only rate limits or historical-range limits are unaddressed.

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 sentences, each carrying distinct payload: result shape first, then the pending-transaction exclusion, then sign semantics, then the warnings contract. Front-loaded with the primary output and free of repetition.

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?

There is no output schema, so the description carries the return-shape burden and does so completely: the metrics, the top-5 lists, and the `warnings` array with its message/reconnect_url fields. Combined with full schema coverage on inputs and readOnly/idempotent annotations, an agent has everything needed to call and interpret it.

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% — both `month` (YYYY-MM with example) and `account_id` (with a pointer to list_accounts) are fully documented in the schema. The description adds no parameter-level detail beyond what is already structured, so baseline 3 applies.

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 precisely (income, expenses, net for one calendar month across connected accounts) and even specifies the aggregation depth (top 5 income sources and expense categories). It is immediately distinguishable from transaction-level siblings, though it never explicitly contrasts with the closer sibling get_spending_summary.

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 output shape — an agent can infer this is the tool for monthly aggregate figures rather than raw transactions. However, there is no explicit when-to-use/when-not guidance and no mention of the natural alternative (get_spending_summary) for budgeting-style breakdowns, so the choice must be inferred.

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 read-only, idempotent, non-destructive, so the safety profile is covered; the description goes further by disclosing the detection algorithm's tolerance (steady interval across five frequencies), the default window and its 13-month caveat for yearly charges, and the `warnings` array with per-bank messages and a conditional `reconnect_url`. That reconnect hint is meaningful behavioral context an agent would otherwise discover only at runtime.

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, front-loaded with the purpose and algorithm before defaults and the warnings detail. The final warnings sentence is dense but each clause carries operational value; only the prose is slightly heavier than necessary.

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 takes on the job of explaining return fields (typical amount, frequency, last charge date, total) and the warnings payload, which it does. Combined with the 100%-covered schema and read-only annotations, an agent has everything needed to call this 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: it explains that the window must span 13+ months for yearly detection, which no individual parameter description states. It does not explain how min_occurrences interacts with interval detection, leaving one 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?

States a specific verb and resource (find recurring charges) and describes the actual detection method — grouping per merchant and identifying a steady weekly/biweekly/monthly/quarterly/yearly interval. This is functionally distinct from siblings like get_merchant_history or get_monthly_cashflow, so an agent can select it without opening the 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?

Gives clear operative guidance for the date window: default is 6 months and yearly charges require 13 months or more, which is exactly the kind of constraint an agent needs to pass correct arguments. It stops short of naming alternatives (e.g. get_merchant_history for single-merchant lookups), so there are no explicit exclusions or sibling routing.

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 read-only, idempotent, non-destructive, but the description goes well beyond them: positive amounts only (credits/refunds excluded), posted transactions only, largest-first ordering, and a warnings array flagging banks that failed to contribute with reconnect_url. That is exactly the kind of data-quality caveat an agent cannot get from 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?

Four sentences, each carrying new information, front-loaded with what is counted and how it is grouped. No filler, no restatement of the title.

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, and the description compensates by describing the return shape (per-group count, average, total_groups, warnings) and the grouping key formats. An agent can predict the response without trial calls.

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 100%, so defaults for limit (20, max 100), start_date (30 days ago), and end_date are already documented in the schema. The description restates the limit and window defaults but adds no syntax or interpretation beyond them; baseline 3 applies.

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 with precise aggregation semantics: total posted spending grouped by category, merchant, month, or week. That is unmistakably distinct from list_transactions or search_transactions in behavior, but the description never names a sibling, so differentiation is inferred rather than explicit.

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 default 30-day window and the group_by options imply the intended use case, but there is no statement of when to pick this over get_monthly_cashflow or get_merchant_history, and no exclusions. An agent must reason from the described output shape to choose correctly.

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 and open-world, so the safety profile is covered. The description adds behavioral context the annotations cannot: the presence of a `warnings` array for banks that failed to contribute, including reconnect_url for reconnection cases, which is exactly the kind of failure-mode disclosure an agent needs.

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, front-loaded with what is listed, then the id contract, then the warnings caveat. No filler and no repetition of the title 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?

There is no output schema, so the description has to carry return-value shape itself, and it does: account types, balances, credit limits, institution, last 4 digits, plus the warnings/reconnect_url structure. Nothing an agent needs to call this correctly or interpret the result 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 tool takes zero parameters, so the baseline is 4. The description still earns that baseline by explaining how the returned `id` value feeds the account_id parameter of sibling tools, which is the only parameter semantics relevant here.

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 ('List every connected account') and enumerates what comes back (balances, credit limits, institution, last 4 digits), so the agent knows exactly what it gets. The plural 'every connected account' clearly separates it from the singular get_account sibling.

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?

Explains the downstream contract clearly: each account's id is what the account_id parameter of other tools accepts, which tells the agent this is the discovery step before per-account calls. It never explicitly says when to prefer get_account over this list, so the alternative is only implied by the plural framing.

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 the operation read-only, idempotent, non-destructive, and open-world, and the description adds substantial behavioral context beyond them. It discloses result ordering, per-category aggregation, the default date window, and partial-data behavior via a warnings array for banks that could not contribute, including reconnect_url semantics.

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 front-loaded with the primary purpose and scope, then adds the sibling relationship and warning behavior without filler. Every sentence contributes information an agent needs either to select the tool or interpret its response.

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 two-parameter read-only tool with rich annotations and no output schema, the description covers the returned metrics, ordering, default time window, and important warning behavior. Nothing material is missing for an agent to call and interpret this tool 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 100% description coverage for both date parameters, including their defaults and YYYY-MM-DD format. The description restates the 90-day default window but adds little parameter-specific meaning beyond what the schema already documents, so the baseline of 3 is appropriate.

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 ('List the spending categories') and specifies the aggregated data returned per category (transaction count and net dollar total, largest first). It also distinguishes the result from sibling behavior by noting these are exactly the values accepted by list_transactions' category parameter.

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 context: default window is the last 90 days, and the returned category values are the ones list_transactions accepts. This implies the natural discovery-then-filter workflow, but it does not explicitly state when not to use this tool or name other alternatives such as get_spending_summary.

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, and the description adds real behavioral context beyond them: cost_basis and gain/loss can be null when the institution doesn't report it, pagination bounds (default 50, max 200), and a warnings array flagging banks that failed to contribute with an optional reconnect_url. It does not cover rate limits or auth requirements, but for a read-only list tool this is well above the annotation baseline.

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, front-loaded with what is returned and how it is ordered, then operational details. Slight waste in restating pagination defaults that the schema already states verbatim, but overall tight and information-dense.

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?

There is no output schema, so the description carries the burden of describing return values — and it does, listing the position fields, the totals, and the warnings array shape with message and reconnect_url. Combined with pagination behavior, an agent has everything needed to call and interpret 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?

Schema description coverage is 100%, so the schema already documents limit, offset and account_id fully; the description mostly restates the limit/offset defaults and max rather than adding new meaning. The account_id narrowing semantics (only results from one account) are already conveyed by the schema, so baseline 3 applies.

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 ("List current investment positions"), enumerates the returned fields, specifies ordering (largest value first) and that portfolio totals are included. This is clearly distinguishable from siblings like list_investment_transactions (transaction history) and list_accounts (account inventory).

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 this is the tool for current position data, but it never explicitly routes the agent away from list_investment_transactions or get_account, nor states prerequisites like needing a connected investment account. The only pointer to a sibling ("Use an account id returned by list_accounts") lives in the schema for account_id, not in the description.

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 read-only, idempotent, non-destructive behavior, and the description goes beyond them with ordering ("newest first"), the implicit 90-day default window, pagination caps, and — most valuably — the `warnings` array explaining that some banks may fail to contribute and may include a `reconnect_url`. That partial-failure disclosure is real behavioral context an agent could not get from the schema.

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 dense sentences with the scope and ordering front-loaded, followed by the non-obvious filtering rule, pagination defaults, and the response caveat. Nothing is redundant with the title and every sentence carries information the agent needs before or after the call.

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 7-parameter read tool with no output schema, the description covers the gap well: it lists the returned fields (ticker, quantity, price, amount), the ordering, the default time window, pagination behavior, and the `warnings` structure. An agent can call this correctly and interpret the response without further documentation.

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 the baseline is 3; the description still adds cross-parameter meaning the schema does not state — that dividends surface as type "cash" with subtype "dividend", which tells the agent how two separate filters must be combined. Pagination and date defaults restated in the description largely duplicate what the schema already documents.

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 a specific verb and resource ("List investment account activity") and immediately enumerates the coverage (buys, sells, dividends, cash events, fees, transfers), which makes the investment-only scope unmistakable. It never names the more generic `list_transactions` sibling, so the differentiation from that tool is left implicit.

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 supplies useful operating context — the default 90-day window and the limit/offset defaults — so an agent knows what it gets without passing filters. However, there is no explicit when-to-use/when-not guidance and no routing to `list_transactions` or `list_holdings` for non-investment or position-level queries; usage must be inferred from the scope statement.

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?

Beyond the read-only and open-world annotations, the description discloses live bank reads, an approximate rate limit of 30 reads per minute, default and maximum date windows, pagination behavior, and a warnings array with reconnect URLs for unavailable banks.

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 front-loaded, opening with the core purpose and then layering only operationally useful details: amount sign, defaults, pagination, rate limits, aggregation alternatives, and warnings. Every sentence contributes information an agent needs to call the tool correctly.

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 nine optional parameters, live external bank data, and no output schema, the description provides the missing operational context: response pagination fields, warning behavior, rate limits, defaults, and when to prefer sibling aggregate tools.

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 schema already covers all parameters at 100%, so the baseline is 3, but the description adds the important sign convention that positive amounts are spending and negative amounts are income. It also clarifies the default date window and practical limit choice even though some of those details overlap 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?

The description states a specific verb and resource: list transactions across connected accounts. It adds scope details such as newest-first ordering and optional filters, which let an agent distinguish it from the summary-oriented siblings it names.

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 explicitly redirects aggregate needs to get_spending_summary and get_monthly_cashflow, explaining that paging through transactions is the wrong approach for totals. It also gives paging guidance to use limit=100 when paging is unavoidable.

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), and the description adds real behavior beyond them: case-insensitive substring matching, newest-first ordering, an implicit 30-day default window, hard pagination caps, and a `warnings` array for banks that could not contribute including a reconnect_url. The partial-failure disclosure with reconnect remediation is exactly the kind of context an agent needs before trusting an empty result.

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?

Purpose and match semantics are front-loaded in the first sentence, which is the right priority. There is minor redundancy — two consecutive sentences open with 'The response includes', and limit/offset defaults are repeated from the schema — but nothing is wasted enough to impede reading.

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 carries the return-shape burden by naming total_count, has_more, and the warnings structure. What remains unstated is whether the search spans all accounts by default and how the date window behaves when only one of start_date/end_date is supplied, which matters for a 6-parameter date-scoped 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%, so every parameter including limit, offset, start_date, end_date, and account_id is already documented in the schema. The description restates the pagination defaults and window but adds no new syntax, format, or edge-case meaning beyond what the schema provides; baseline 3 applies.

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 plus matching semantics ('case-insensitive substring match') and ordering ('newest first'), so the agent knows exactly what the tool does. However, it never distinguishes itself from the sibling list_transactions, which an agent could easily choose instead when it wants a transaction list.

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 search semantics and by the stated default 30-day window, and the pagination guidance says to page with limit/offset. But there is no explicit 'use this when X, use list_transactions when Y' routing, and no guidance on when to supply account_id versus searching broadly.

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