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. Changed1 schema field changed
    • addedInput schema / required
      Added value: +[]
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.