Model Context Protocol server for YNAB (You Need A Budget) providing tools to read and modify budget data, transactions, and accounts
YNAB MCP demonstrates solid tool design with clear naming, comprehensive parameter schemas, and good descriptions. All 5 tools follow verb_noun convention (list_plans, get_budget, get_transactions, modify_transactions, modify_budget). Schemas are well-structured with proper types and enums. However, output schemas are not explicitly documented in the source, descriptions could be more concise (some exceed 200 chars), and error handling guidance is minimal. Tool composition is strong, tools chain well (list_plans → get_budget/get_transactions → modify_*). Destructive operations (modify_transactions delete, modify_budget) lack confirmation/dry-run patterns.
Get budget data for a plan. Views: - overview: accounts + category groups + current month (start here) - month: full budget for a specific month with all categories - category: single category deep-dive with goal progress - scheduled: upcoming recurring/scheduled transactions - money_movements: how money was budgeted across categories for a month
Fetch transactions for a plan, account, or category with optional filtering by date, cleared status, and type (unapproved, uncategorized, matched)
List all accessible YNAB budget plans with their IDs and names
Modify budget allocations and category structure. - set_amount: Change budgeted amount for a category in a month - update_category: Rename or hide/unhide a category - set_goal: Update a category's goal target amount and/or target date Note: Creating categories/groups requires the YNAB app.
Create, update, delete, or import transactions. Dollar amounts are auto-converted to YNAB milliunits. - create: Add new transactions (batch supported) - update: Modify existing transactions (batch supported) — use for clearing, categorizing, editing - delete: Permanently remove a transaction - import: Trigger sync from linked bank accounts
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing response structure. get_budget, get_transactions, modify_* lack explicit return type documentation.
Destructive operations (modify_transactions delete, modify_budget set_amount) lack confirmation or dry-run support. Agents can permanently delete transactions or overwrite budgets without verification.
Error handling guidance missing. Tools do not document what errors are retryable, user-fixable, or fatal. No recovery hints (e.g., 'If category not found, call get_budget to list valid categories').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
get_budget description is 280+ chars, exceeding the 200-char baseline for optimal LLM parsing. The multi-view explanation is valuable but could be condensed or moved to parameter descriptions.
modify_transactions and modify_budget descriptions do not explicitly state they modify state. LLMs need clear 'This creates/updates/deletes data' language to reason about idempotency and retry safety.