Skip to main content
Glama
avenir-mcp

avenir-mcp

Age of Money month by month

get_age_of_money
Read-onlyIdempotent

Shows YNAB's Age of Money in days month by month, with the latest figure, change and direction, so you can see whether your buffer is growing or you're living on last month's income.

Instructions

YNAB's Age of Money: how old the money spent is today, and its trend month by month.

Use it for "how old is my money?", "am I living on last month's income?" or "is my buffer growing?". The figure is YNAB's own, in days: how long, on average, money stayed in the budget accounts before being spent, the oldest money spent first. Over 30 days means living on last month's income. months_count counts back from the current month, included, so 1 gives this month alone and the default 12 the year up to it; a plan that holds fewer months gives those, and says so in the notes. The answer gives each month's figure, the latest, the change and its direction over the period. A month YNAB had not enough history for comes back null, not as an error, and the notes name those months. Relay the notes with the figures. For how long the money would last without income use get_runway. One YNAB request, the list of months; changes nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "plan_id": "<plan_id>"
    },
    "name": "get_age_of_money"
  }
}

Input Schema

NameRequiredDescriptionDefault
plan_idYesYNAB plan id or 'last-used'.
months_countNoMonths to show, the current one included, 1 to 24 (default 12).

Output Schema

NameRequiredDescriptionDefault
daysYesThe latest Age of Money, in days; null when YNAB gives none.
as_ofYesThe month of that figure, YYYY-MM: the current one unless YNAB has none for it.
notesYesHow YNAB counts, and what is missing, to tell the user.
trendYesThe direction of that change; null with fewer than two figures.
changeYesDays gained (positive) or lost from the first month with a figure to the latest; null with fewer than two figures.
monthsYesThe months up to the current one, oldest first.
messageYesThe conclusion in one sentence or two, for the agent to relay.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnly/idempotent annotations it discloses the call footprint ('One YNAB request, the list of months; changes nothing'), the null-not-error behavior for months lacking history, the instruction to relay notes with figures, and the truncation behavior when a plan holds fewer months than requested. These are exactly the traits an agent needs and none are in 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.

Conciseness4/5

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

Front-loaded with the metric definition, then usage, then parameter behavior, then the sibling pointer — a sensible order with no filler. It is on the long side with some clause-heavy sentences, but nearly every sentence carries a distinct fact.

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

Completeness5/5

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

An output schema exists so return shape needn't be spelled out, yet the description still flags the aggregate fields (latest, change, direction) and the null case. Nothing an agent needs to call this correctly or interpret the result 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for months_count: it counts back from the current month inclusively (1 = this month alone) and explains what happens when the plan has fewer months of history than requested. plan_id semantics are left entirely to the schema ('last-used'), which is the only shortfall.

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 metric (YNAB's Age of Money), what it measures in days, and that it is returned month by month with a trend. It also names the sibling it is not ('For how long the money would last without income use get_runway'), so an agent can distinguish it from get_runway and get_spending_trends without opening schemas.

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

Usage Guidelines5/5

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

Gives concrete user phrasings that should trigger it ('how old is my money?', 'am I living on last month's income?') and explicitly routes the adjacent case to get_runway. The condition that selects this tool versus the alternative is stated outright.

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