Banking Assistant (Metabind demo)

Net Worth Trend

net_worth_trend

Read-onlyIdempotent

Render net_worth_trend: Net worth: current total, change over the period, a trend chart, and the account balances behind it. It loads its own data. To compare periods against each other pass chartStyle:'bar' plus groupBy ('year' for this-year-vs-last-year, 'month' for month-by-month) — each bar is that period's closing balance.

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": "net_worth_trend"
  }
}

Input Schema

Name	Required	Description	Default
`note`	No	Usually 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.
`period`	No	Window: 7d, 30d, mtd (this month so far), lastMonth (the whole previous calendar month), 3mo, 6mo, ytd, 1y or all. Ignored when startDate/endDate are given. Defaults to 1y.
`endDate`	No
`groupBy`	No	One bar/point per period, carrying that period's closing balance. Set it to compare periods: 'year' for "this year vs last year", 'month' for "month by month", 'quarter' for "by quarter". Leave auto for a plain trend.	auto
`nextSteps`	No	One 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.
`startDate`	No
`chartStyle`	No	'bar' compares periods against each other as closing balances; 'line' is the continuous history.	line

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Changed1 schema field changedSep 30, 2026
- addedInput schema / required
```
Added value: +[]
```
First observedSep 27, 2026

TDQS

A3.6/5.0

Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

All Banking Assistant (Metabind demo) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.