Skip to main content
Glama
avenir-mcp

avenir-mcp

Forecast the balance

forecast_balance
Read-onlyIdempotent

Project your budget balance month by month and see when money would run out. Estimates scheduled bills, recurring charges, and income to flag the first shortfall.

Instructions

Project the balance month by month and say when money would run out.

Starts from today's balance of the open on-budget accounts (or those given). For the current month, what was already spent or received since the 1st is deducted from the monthly averages, so only what is left is projected. Assumes, and returns as assumptions so the user can correct them: YNAB's scheduled transactions on their dates, whatever their frequency, a yearly bill included, charges that recur in the last 4 months (same payee, stable amount), the average of all other spending over the last 3 months, and what you pass. A payee with a schedule is projected by that schedule alone, and transfers between the projected accounts are left out. What you pass is the expected monthly income (default: the last 3 months' non-recurring inflows, which may include one-off money such as capital injections) and one-off amounts such as a tax bill (negative) or a refund (positive). Amounts in currency units. lowest is the lowest point within a month; first_shortfall is the first month it goes below zero. For a month already gone use get_monthly_summary, or get_spending_trends to compare several; for how long today's money would last with no income at all, get_runway. 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>",
      "until": "<until>"
    },
    "name": "forecast_balance"
  }
}

Input Schema

NameRequiredDescriptionDefault
untilYesLast month to project, YYYY-MM, at most 24 months ahead.
plan_idYesYNAB plan id or 'last-used'.
one_offsNoExpected one-off amounts: {date YYYY-MM-DD, amount, label}; not those already scheduled in YNAB, which are counted.
account_idsNoAccounts to include (from list_accounts); default all open on-budget accounts.
monthly_incomeNoIncome expected each month, replacing the income found in the history (recurring or average) and scheduled in YNAB; default: what they show.
variable_monthlyNoMonthly spending besides recurring charges (negative); default: the last 3 months' average.

Output Schema

NameRequiredDescriptionDefault
monthsYesThe projected months.
messageYesThe conclusion in one sentence, for the agent to relay.
accountsYesNames of the accounts projected together.
assumptionsYesEverything the projection assumed, to check with the user.
start_balanceYesTheir total balance today.
first_shortfallYesFirst month whose lowest balance is below zero; null if none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only and idempotent behavior, but the description goes further: it spells out the projection model (scheduled transactions, 4-month recurrences, 3-month averages), the mid-month deduction rule, and exclusions (transfers between projected accounts, scheduled payees). It also says the assumptions are returned so the user can correct them, which is exactly the kind of behavioral context annotations cannot carry.

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 core purpose and outcome, then method, then alternatives. It is dense rather than bloated: every clause about assumptions, exclusions, and defaults carries information. A minor deduction for being a single sprawling paragraph that could be split for readability.

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?

Given 6 parameters, an output schema, and read-only annotations, the description is complete: it covers methodology, defaults, exclusions, return fields like `lowest`, `first_shortfall`, and `assumptions`, and the boundary against sibling tools. An agent has everything needed to call it correctly and interpret the result.

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: it explains that one_offs are not those already scheduled in YNAB, that monthly_income replaces historical and scheduled income, and that defaults are derived from 3 months of non-recurring inflows. The only small gap is that 'variable_monthly' is described mostly as it is in the schema, without elaborating on its interaction with recurring charges beyond the parenthetical.

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 verb and resource plus the key outcome: 'Project the balance month by month and say when money would run out.' It also names the sibling tools it is not (get_monthly_summary, get_spending_trends, get_runway), so the agent can separate it from them 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?

Explicit routing: past months go to get_monthly_summary, multi-month comparison to get_spending_trends, and no-income survival to get_runway. The phrase 'For a month already gone...' gives a clear when-not condition, and 'Changes nothing' clarifies it is advisory only.

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