Skip to main content
Glama
LandonSchropp

ynab-mcp-server

Balance Forecast

ynab_balance_forecast
Read-only

Project your combined account balance over the next N days using scheduled transactions, revealing end-of-day running balances and the lowest point to spot upcoming shortfalls.

Instructions

Projects the combined balance of your accounts over the next N days (from today in UTC) from scheduled transactions only: the starting balance, the scheduled events, the end-of-day running balance and the lowest point. Income or spending that is not scheduled in YNAB is not in the forecast. Transfers between two included accounts (credit card payments too) net to zero; a transfer to an account outside the forecast counts as money leaving, and one from an account outside it as money arriving. Split schedules are counted leg by leg. Occurrences whose date has passed but that YNAB has not entered yet count on the first day, marked overdue with their scheduled_date and summarised in overdue_schedules. Where YNAB does not give the second date of a twice-a-month schedule, it is approximated as 15 days after the first. Events are capped by limit; the running balance, low point and ending balance always cover every day. For past income versus spending, use ynab_cash_flow; to list the schedules themselves, use ynab_list_scheduled_transactions.

Input Schema

NameRequiredDescriptionDefault
daysNoHow many days ahead to project (default: 30, max: 365)
limitNoMaximum number of events to return, earliest first (default: 100; 0 leaves them out). event_count, the running balance, low point and ending balance always cover every event.
planIdNoThe plan ID (optional, defaults to YNAB_PLAN_ID; budgetId is a deprecated alias)
budgetIdNoDeprecated alias of planId (still accepted)
accountIdsNoAccounts to include (IDs from ynab_list_accounts). Defaults to every open on-budget account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already establish read-only, open-world, non-destructive behavior, but the description goes well beyond them: overdue occurrences are placed on day one and marked, twice-a-month schedules without a second date are approximated at +15 days, split schedules are counted leg by leg, and transfers net to zero or count as inflow/outflow depending on inclusion. It also discloses that limits cap event rows while balances always cover every day.

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?

The description is front-loaded with what is projected and what it returns, then proceeds through the accounting rules and alternatives. Every sentence carries behavioral information, though the single dense paragraph could be made easier to scan for such a rule-heavy tool.

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?

For a read-only forecasting tool with no output schema, it covers outputs, inclusion rules, overdue handling, approximation rules, transfer netting, limit behavior, and routing to alternatives. An agent has enough to call it correctly and interpret results without further questions.

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% and already documents days, limit, planId, budgetId, and accountIds. The description adds genuine meaning beyond the schema for accountIds by explaining how included versus excluded accounts affect transfer accounting, and clarifies that the projection starts today in UTC. This is above the baseline 3 but not maximally additive since most parameter definitions are already well covered.

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: projects the combined account balance over the next N days from scheduled transactions, and enumerates the outputs (starting balance, scheduled events, end-of-day running balance, lowest point). An agent can distinguish this immediately from the sibling listing and cash-flow tools.

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?

Explicitly scopes the tool to scheduled transactions only and warns that unscheduled income/spending will not appear. It names two alternatives with their selecting conditions: ynab_cash_flow for past income versus spending, and ynab_list_scheduled_transactions to list the schedules themselves.

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