YNAB MCP Server

Get plan

get_plan

Read-only

Fetches the YNAB plan’s name, covered months, and currency/date formats so amounts can be written as the user sees them in YNAB.

Instructions

Get the plan's name, the months it covers, and its currency and date formats. Use the currency format to write amounts the way the user sees them in YNAB.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`id`	Yes	The plan's ID, as configured
`name`	No	The plan's name
`last_month`	No	Latest month
`date_format`	Yes	How the plan writes dates
`first_month`	No	Earliest month
`currency_format`	Yes	How the plan writes amounts of money
`last_modified_on`	No	When anything in the plan last changed

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 26, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value on top: the exact fields returned and the practical rule that the returned currency format should drive how amounts are displayed to the user. It does not discuss caching or whether plan settings can shift mid-session, but with annotations carrying the safety burden this is solid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two short sentences, front-loaded with the returned fields, then the one actionable tip. Nothing is repeated or padded.

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?

Zero params, no nested objects, an output schema, and read-only annotations mean the description only needed to frame purpose and any non-obvious usage. It does that, plus the currency-format tip. Minor gap: it never clarifies which plan is returned (last-used vs. default), which an agent might wonder about.

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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument call that returns the current plan's metadata, consistent with the empty schema.

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 and resource ('Get the plan') and enumerates exactly what comes back: name, months covered, currency and date formats. That field list implicitly separates it from get_plan_month and list_plan_months, which drill into per-month data, though no sibling is named outright.

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?

The only guidance is output-side: 'Use the currency format to write amounts the way the user sees them in YNAB.' There is no statement of when to call this versus get_plan_month or list_plan_months, and no prerequisites; usage is inferred from the zero-arg, plan-level nature of the tool.

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