Banking Assistant (Metabind demo)

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds the meaningful behavioral trait that the output is raw numbers intended for reasoning rather than presentation, which is genuine context 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 terse sentences with the resource stated first and the routing rule second. No filler; every clause earns its place.

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?

Output schema exists and annotations are rich, so return values need not be explained. The description covers the key reasoning-vs-display decision, which is the main ambiguity for this tool; only minor pagination/size nuance in the summary parameter is left to the schema.

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 all five parameters (period, startDate, endDate, groupBy, summary) are already well documented in the schema, including enum behavior and defaults. The description adds no parameter guidance, so the 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 exactly what comes back — net worth history plus account balances — a specific resource and scope. It also names the sibling it is not (net_worth_trend), so an agent can route between them without opening either 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 an explicit selection rule: use this tool when you need numbers to reason with, and use net_worth_trend when the goal is display. The alternatives condition is clear, though no other exclusions or prerequisites are covered.

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), and an output schema exists, so the remaining burden is light. The description adds that output includes a prior-period comparison and that the data is meant for reasoning rather than presentation, but says nothing about precision, rounding, or coverage gaps that an analyst would care about.

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, zero filler, with the core capability and the sibling routing stated up front. Nothing redundant with 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?

With annotations covering safety and an output schema defining the return shape, the description only needed to convey scope and the sibling split, which it does. Period semantics and the summary flag are fully documented in the schema, so no agent-relevant information 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%, including a full enum for period and a detailed explanation of the summary flag, so the schema carries parameter meaning. The description adds no parameter-specific syntax or defaults, which is the expected baseline when the schema is complete.

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 the resource precisely — categorized spending plus a prior-period comparison — so the agent knows what comes back without opening the schema. It also names and distinguishes itself from the sibling spending_breakdown (analysis vs display), though it never uses an explicit verb for the retrieval action.

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?

'Numbers to reason with — to display, use spending_breakdown' gives an explicit alternative and the condition that selects it. It stops short of stating exclusions or prerequisites (e.g., when prior-period comparison is unavailable for period=all), so it is clear but not exhaustive.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the full safety profile is covered by structured data. The description adds the useful framing that the output is raw numbers for reasoning rather than a rendered view, but discloses nothing about pagination, rate limits, or permission requirements. Moderate added value against a strong annotation set.

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 with zero filler; the domain statement is front-loaded and the routing hint follows immediately. Every clause earns its place.

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?

An output schema exists so return values need no explanation, and annotations cover the safety profile, leaving little for the description to carry. The remaining minor gap is that the status filter's behavior (active vs all) is never surfaced in prose, but for a zero-required-parameter read tool this is close to 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 single status parameter has 100% schema description coverage including an enum and a default of "active", so the schema fully documents it. The description never mentions status or the active/all distinction, adding no meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

"Recurring-charge detection" states the resource/domain clearly, and combined with the get_subscriptions name an agent understands it retrieves subscription data. It also implicitly distinguishes itself from the sibling "subscriptions" card, though it never uses an explicit verb like "returns" or "lists".

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?

"Numbers to reason with — to display, use the subscriptions card" explicitly routes the agent between this data tool and the display sibling, which is exactly the kind of alternative-selection guidance that matters here. It stops short of an explicit when-not for the status filter or for adjacent siblings like get_transactions.

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, non-destructive and closed-world, so the safety profile is covered. The description adds the 'raw' vs 'aggregated' distinction and a retention claim, but nothing about pagination, cost, or precision. Note the stated '~12 months of history' conflicts with the schema's own period description ('feed covers ~25 months'), which is a description-vs-schema inconsistency rather than an annotation contradiction.

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 terse fragments with zero filler; the core capability leads and the routing hint is front-loaded rather than buried. Every clause carries 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?

An output schema exists, so return structure need not be described. However, the description's history claim (~12 months) contradicts the schema's ~25-month feed, which can mislead an agent planning an 'all' or 1y window, and the description omits that the tool also serves count/total-only requests. Usable but not fully trustworthy for planning.

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%, with sort, limit, period, category and merchant all richly documented in-schema (including the limit=0 totals trick and date precedence). The description only echoes the category/merchant filters, adding essentially nothing the schema has not already said — baseline 3 is correct.

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 ('Raw transactions'), the two filter axes (category or merchant), and explicitly routes display-oriented callers to the sibling transaction_list. An agent can distinguish this from transaction_list without opening either 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 an explicit when/when-not pair: use this for 'numbers to reason with', use transaction_list 'to display'. It does not distinguish this tool from the other analytical siblings (spending_breakdown, subscriptions, net_worth_trend), so it stops short of fully disambiguating the tool set.

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=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioral fact beyond them: 'It loads its own data,' telling the agent no prerequisite data call is needed. It stops short of describing pagination or rendering constraints.

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, tightly front-loaded: what it renders, then the comparison recipe. The opening 'Render net_worth_trend:' slightly restates the tool name, a minor redundancy, but nothing else is wasted.

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, no-required-args card tool with no output schema, the description covers the output content, the comparison workflow, and the self-loading behavior. The detailed note/nextSteps guidance lives in the schema, which is acceptable; the description is complete enough to call 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 71%, so structured fields carry much of the load (period, groupBy, note, chartStyle all have descriptions). The description nonetheless adds value by explaining the chartStyle+groupBy interaction — that each bar is that period's closing balance — which neither schema field states alone.

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 (render) and resource (net worth trend) and enumerates what the card shows: current total, change over the period, a trend chart, and account balances. It distinguishes this card-rendering tool from data tools only implicitly, but the output content is concrete enough for an agent to select it.

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 gives one clear usage rule — pass chartStyle:'bar' plus groupBy to compare periods — with examples ('year' for this-year-vs-last-year). However it never says when to prefer this over siblings like get_net_worth or trend_card, so the routing guidance is incomplete.

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), so the bar is lower. The description still adds genuinely non-obvious behavior: the card 'loads its own data', passing highlight dims everything else, matching of category names is forgiving, and the card ignores nextSteps. This is real context an agent cannot 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?

Front-loaded with the card's purpose, then the usage rule, then the highlight caveat. Roughly three dense sentences with no filler. Slightly heavy in the middle sentence (a long appositive clause), but every clause earns its place.

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, but the description explains what the card renders (composition bar plus ranked list) and how its interactive parts behave, which is what an agent needs. Combined with full schema coverage and annotations, nothing required to call 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?

Schema description coverage is 100% and the parameter descriptions are themselves rich, so the baseline is 3. The tool description reinforces and prioritizes the highest-stakes semantic — that highlight solves a different question than the default period-only call — adding a small amount of meaning on top of 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?

It states a concrete verb-plus-resource: render a spending breakdown card made of 'a composition bar plus a ranked category list' for a period. That is specific and far better than restating the title. It does not, however, distinguish itself from the sibling get_spending_breakdown, which an agent could plausibly confuse with this rendering tool.

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?

Explicit when-to-use guidance: pass period alone for a broad opening question, use highlight only on a follow-up about specific categories. It also names the failure mode (highlight dims the rest and hides the answer on an opening question) and even routes the note/drillPrompt behavior. Nothing is left to inference.

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, non-destructive, and closed-world, so the safety profile is fully covered. The description adds one genuinely behavioral fact beyond them — that it self-loads its data, sparing the agent an unnecessary prerequisite call — and describes the rendered output shape. It stops short of stating side effects on the host UI (e.g., whether the card replaces or stacks).

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, front-loaded with the verb and the card's payload, with no filler. The stacked-colon phrasing ('Render subscriptions: Recurring charges: ...') is slightly awkward 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?

Sibling tools suggest a render-card family, and with no output schema the description does the work of telling the agent what the card surfaces (monthly total, per-row cadence, next charge, flags). Combined with the exhaustive schema, an agent has enough to call it correctly; only explicit sibling routing 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% and the parameter descriptions are unusually thorough, so the baseline of 3 applies. The description body adds no parameter-level detail (no mention of view cuts, status, note, or nextSteps) beyond what the schema already supplies.

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 ('Render') and resource (subscriptions), and enumerates the card's contents: total monthly cost, per-row cadence, next charge date, and New/price-increase flags. It implicitly separates itself from data-fetch siblings like get_subscriptions by saying it 'loads its own data', though it never names that sibling directly.

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 phrase 'It loads its own data' implies the agent should call this instead of first fetching via get_subscriptions, which is useful implied routing. However, there is no explicit when-to-use/when-not statement or named alternative in the description; the rich view-selection guidance lives entirely in the schema, not the description body.

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 (readOnlyHint, idempotentHint, destructiveHint=false), so the description's job is to add beyond that. It does: 'It loads its own data' discloses that this tool self-fetches rather than requiring a prior query, which is real behavioral information. It stops short of richer detail (rendering latency, whether the card persists state) so it lands at 4 rather than 5.

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 rendered, then the filter-resolution rule, then the hard exclusion and alternative. No padding. It is dense but every clause carries routing or behavior information; it falls just short of the two-line ideal seen in the top example.

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 must orient the agent on what comes back — it does ('the window total plus the matching transactions'). With 10 parameters all fully documented in the schema and safety fully covered by annotations, the only unaddressed area is any failure/empty-result behavior, which is minor for a read-only render 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 the baseline is 3 and the schema already carries per-parameter detail. The description's plain-term resolution ('restaurants', 'groceries', 'gas' resolve to categories) and the 'omit both filters' rule add marginal value on top of what category/merchant already document, but it introduces no parameter syntax the schema lacks.

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 precise verb+resource ('Render transaction_list'), and the scope ('Individual purchases for a category or a merchant: the window total plus the matching transactions'). It explicitly distinguishes itself from sibling trend_card by name and function, so an agent can route between them without opening either 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?

Names the exclusion condition outright ('Do NOT use this when the user asks how much they spent over the last 3, 6 or 12 months') and names the alternative (trend_card with chartStyle:'bar'). It also tells the agent how to get 'all spending' by omitting both filters, closing the main usage 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?

Annotations already establish the safe read-only, idempotent profile, and the description goes well beyond them: the note parameter explains the round-trip cost of an extra call and forbids guessed numbers, `prompts` explains that omission triggers an auto-built drill-down from `name`, and nextSteps documents the icon table constraint and 'card itself ignores them'. This is unusually rich behavioral context for a render 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?

Purpose is front-loaded in the first clause, and the dense follow-up sentences each carry a distinct rule (upIsGood, bar-for-comparison, series stacking, items). It is a single long paragraph, so a small structural cost, but little is wasted.

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 14-param, no-required-param card renderer with no output schema, the description covers the decisions that matter (chart style, polarity, stacking, composition, note discipline). It stops short of tying start/current/change/change_pct together, which the schema descriptions only partially cover.

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?

With 14 params and 57% schema coverage, the description meaningfully supplements the schema: it explains point ordering, the `series` repetition convention for stacking, the difference between line and bar, and the role of `items` as composition rows. A few params (start, current, periodLabel, change_pct interplay) are left mostly to schema defaults, so not a full 5.

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 render verb and resource ('Render trend_card: Any metric over time') and defines scope precisely with 'has no dedicated card — one category's spend by month, a series you computed.' This scope clause is what separates it from dedicated siblings like net_worth_trend and spending_breakdown.

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: use this for metrics without a dedicated card, set upIsGood=false for cost-like metrics, and use chartStyle:'bar' whenever the user compares periods. It does not, however, name the specific sibling cards it should yield to, leaving the agent to infer which metrics already have dedicated cards.

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