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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "trend_card"
  }
}

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

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.