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 readOnly, idempotent, non-destructive, non-openWorld, so the safety profile is fully covered. The description adds real context beyond them — that the card self-loads its data (no chained fetch required) and that nextSteps is ignored by the card — but says nothing about latency, rate limits, or data freshness.

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 card's contents before the comparison-mode rule. It is dense but every clause carries information; minor redundancy with the duplicated schema-level description text is the only waste.

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 seven optional parameters and no output schema, the description supplies what the card renders, that it self-loads, and how to trigger comparison mode — enough for correct invocation. Remaining gaps (date window defaults, note etiquette) are already carried by the parameter descriptions in 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 coverage is 71%, so the baseline is 3, and the description earns above that by explaining the interaction between chartStyle and groupBy — that bar mode makes each bar a period's closing balance, which is a semantic the enum values alone don't convey. It does not cover startDate/endDate or period defaults, which the schema handles.

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 (net_worth_trend card) plus exactly what the card contains: current total, period change, trend chart, and underlying account balances. 'It loads its own data' hints at the render-vs-fetch split that separates it from get_net_worth, but no sibling is named explicitly, so the differentiation is inferred rather than stated.

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 explicit operative guidance for one mode — pass chartStyle:'bar' with groupBy to compare periods, with 'year' mapped to this-year-vs-last-year and 'month' to month-by-month. However there is no tool-level when-to-use guidance against siblings like get_net_worth or trend_card, and no statement of when this card is the wrong choice.

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 profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds meaningful behavior beyond that: it loads its own data, highlight dims all other categories, the card ignores nextSteps, and drillPrompt carries an angle forward. These are real operational traits an agent could not infer 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?

It is front-loaded with what the card renders and then the period-vs-highlight decision, with no filler. However, its highlight sentence substantially duplicates the schema's highlight description, so it is slightly redundant rather than maximally tight.

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?

All five parameters are optional, schema coverage is 100%, and no output schema is needed for a render-into-card tool. Given that, the description covers everything an agent needs to call it correctly, especially the key highlight-vs-period judgment.

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 per-parameter descriptions are unusually rich, so the schema already carries the semantics. The description largely restates the highlight-vs-period rule that the schema's own highlight description spells out, adding only marginal extra meaning. 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?

The description gives a specific verb and resource: it renders a spending split by category, as a composition bar plus a ranked category list, for a period. The opening 'Render spending_breakdown:' restates the name, but the following clause adds real substance, and 'It loads its own data' hints at the render-vs-fetch distinction from get_spending_breakdown. It does not explicitly name that sibling, so it falls short of 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?

It clearly states when to pass period alone (broad 'where did my money go' questions) versus when to use highlight (genuine follow-ups about particular categories), and warns that highlight on an opening question hides most of the answer. That is strong when/when-not guidance, though it never names an alternative sibling tool to route to.

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, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful context beyond them: 'It loads its own data' tells the agent this render is self-sufficient and needs no prior data call, and it discloses the rendered payload since there is no output 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?

Two short sentences, front-loaded with the verb and resource, then the payload, then the self-loading constraint. No filler and nothing that fails to earn 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?

With no output schema, the description compensates by enumerating what the card renders, and 'It loads its own data' prevents a redundant get_subscriptions call. What is missing is any tie-break against the sibling card tools, but for a zero-required-param renderer the essentials are covered.

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 enum parameters (view, views) are documented exhaustively in the schema itself, including when to pick each cut. The tool description adds nothing about parameters, so the baseline 3 applies — the schema does all the work.

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'), then enumerates the card's contents: total monthly cost, one row per subscription with cadence, next charge date, and New/price-increase flags. The 'Render' verb plus 'It loads its own data' implicitly separates it from the data-fetching sibling get_subscriptions, but it never names that sibling, so differentiation is inferred rather than stated.

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 body offers no explicit when-to-use framing against siblings like get_subscriptions or spending_breakdown; the only guidance is the implicit 'It loads its own data', which tells the agent not to prefetch. The detailed cut-selection advice lives in the view/views parameter descriptions rather than the tool description, leaving tool-level usage 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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description still adds non-obvious behavior beyond them: the card loads its own data (no prior call needed) and the view/views interaction lets the user switch cuts without a new request. It does not discuss data freshness or account scope, which keeps it short of a 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 purpose before the routing rule, and every sentence carries information. The exclusion sentence is long but earns its length by naming both the tool and parameter value to use instead.

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 10 optional parameters, 100% schema coverage, no output schema and annotations covering safety, the description covers what an agent must know to select and call it: what it renders, how filters resolve, and which sibling to use instead. Minor gaps remain around data scope/freshness, but nothing blocks correct invocation.

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% and each parameter carries a rich description, so the baseline is 3. The top-level description still contributes cross-parameter semantics the schema states only locally: that plain terms like 'restaurants' resolve to the category filter and that omitting both filters means all spending.

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+resource (renders a transaction list) and pins down the scope: individual purchases for a category or merchant, window total plus matching transactions. It also pre-empts the closest sibling confusion by naming trend_card as the tool for period comparisons, so an agent can route 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?

It gives an explicit when-not rule ('Do NOT use this when the user asks how much they spent over the last 3, 6 or 12 months'), names the alternative tool and even the required parameter value (trend_card with chartStyle:'bar'). It also supplies positive usage context: plain terms resolve to categories, omit both filters for all spending.

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 readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely useful behavior: the note round-trip delay warning, the auto drill-down built from `name` when prompts are omitted, and the 'always supply 2-3' nextSteps that the card ignores. This goes beyond the structured safety profile.

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-loads the core scope ('no dedicated card') before moving into usage rules. Dense but nearly every sentence carries an actionable instruction; it reads as one long run-on paragraph rather than clearly separated guidance.

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 bears the burden of conveying what the card shows and how it renders, which it largely does through the chart-style and items discussion. Given 14 parameters, a few behavioral parameters are under-described, but nothing critical to correct invocation 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?

With 57% schema coverage, the description meaningfully compensates: it defines the {label, value} point shape and display order, explains the `series` stacking mechanic with legends, and clarifies items as the composition behind the number. Several params (start, current, change_pct, periodLabel, title) remain explained only by their names, leaving some gaps.

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 action and resource, and explicitly carves out its niche with 'Any metric over time that has no dedicated card,' which directly distinguishes it from sibling card tools like net_worth_trend and spending_breakdown. An agent can tell immediately which card to reach for.

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 conditional guidance: 'no dedicated card' for selection, upIsGood=false for cost-like metrics, and chartStyle:'bar' whenever periods are compared. The alternative (dedicated cards) is implied but never named explicitly, so routing is clear but not fully spelled out.

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