Skip to main content
Glama

Banking Assistant (Metabind demo)

trend_card

trend_card
Read-onlyIdempotent

Render trend_card: Any metric over time that has no dedicated card — one category's spend by month, a series you computed. Points are {label, value} in display order. Set upIsGood=false for cost-like metrics. Use chartStyle:'bar' whenever the user compares periods — month by month, or over the last 3/6/12 months; give each point a series name (repeating the label once per series) to stack them with a legend. Pass items to list the composition behind the number.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoUsually omit this. Optional one-line insight rendered inside the card. Only pass it when you ALREADY have the figures in hand from a call you made for another reason — never make an extra tool call just to write a note, because that round trip delays the card itself. When you do add one, say something the card does not already show (what drove a change, what to watch), in one sentence, and never guess a number.
itemsNoOptional rows under the chart — the composition behind the number (accounts behind a net worth, categories behind a month's spend). Each is { name, detail, value, color?, prompts? }. `color` is a named colour for the dot ('blue', 'green', …); omit it and rows are coloured in order. `prompts` are follow-up questions offered when the row is tapped — each string is shown as the menu label AND sent to the assistant verbatim, so keep them short and self-contained ('How has my Brokerage changed?', not 'changed?'). OMIT `prompts` unless a row needs something its name cannot imply: left out, the card builds its own drill-down from `name`, which saves you writing the same sentence once per row.
startNo
titleNoTrend
changeNoThe change over the period, in the same unit as `current`. Send it together with `start` whenever you have them: the card leads with this figure, and left out it has to work back from `change_pct`, which is close but not the real number.
pointsNo
currentNo
upIsGoodNofalse for cost-like metrics: an increase renders red, a decrease green.
nextStepsNoOne short follow-up the user might ask next, in the form icon|question — 'calendar|Show me last month'. Phrase the question the way the user would say it, and take the icon from the table in the app instructions; any other name renders blank. Always supply 2-3. The card itself ignores them.
change_pctNo
chartStyleNo'bar' draws discrete bars on a labelled x axis — better for comparing periods against each other, and the only style that stacks series. 'line' is the continuous trend.line
periodLabelNoPast 12 months
valueFormatNoHow the hero value and change are formatted.currency
valueSuffixNoOptional unit appended to values, e.g. ' subs' or '/mo'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish the safe read-only, idempotent, non-destructive profile, so the description is free to add rendering behavior — points/items composition, the bar-stacking-with-legend behavior when a `series` is repeated, and the metric-direction color semantics. It goes beyond the annotations, though it doesn't describe period/pagination or how the card is surfaced back to the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences, front-loaded with scope then the chart-style rule then composition, with no filler. The 'Render trend_card:' opener is mildly redundant with the name, but the rest is tightly written.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, no-output-schema rendering tool this covers the essentials an agent needs — scope, direction-of-good, chart style, series stacking, composition rows. It leaves minor gaps (periodLabel/valueFormat interplay, title), but the parameter-level schema descriptions here are unusually rich and fill most of those.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 57% and several parameters (points, series, start, current, periodLabel, change_pct) have no schema descriptions, so the description has to compensate — and it does, explaining points as '{label, value} in display order', the `series` stacking convention, and upIsGood direction. It adds real meaning beyond the schema but doesn't cover every undocumented field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (Render) and resource (trend_card) and immediately scopes it to 'Any metric over time that has no dedicated card', with concrete examples ('one category's spend by month, a series you computed'). That 'no dedicated card' clause implicitly routes the agent away from siblings like net_worth_trend and spending_breakdown, so the tool is distinguishable without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear conditional rules: 'Set upIsGood=false for cost-like metrics', and 'Use chartStyle:bar whenever the user compares periods — month by month, or over the last 3/6/12 months'. The 'no dedicated card' framing is the when-to-use gate and implies when-not (use the dedicated card instead), though no sibling is named explicitly as the alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.