Skip to main content
Glama
diegoaad

YNAB MCP server

by diegoaad

YNAB MCP server (Phase 1)

A local, read-only MCP server for one personal YNAB plan. It runs over stdio, fetches current data on demand from https://api.ynab.com/v1, and does not save financial data, cache responses, or send telemetry. Python 3.12+ and uv are required.

Set up

  1. Create a YNAB Personal Access Token (PAT) in your YNAB account and keep it in your local MCP host configuration. The server does not load .env automatically. .env.example contains placeholders only; .env is ignored by Git.

  2. In this audited checkout, run uv sync --frozen.

  3. Set YNAB_PAT but leave YNAB_PLAN_ID unset, then start the server and call list_plans to find your plan UUID. Setup mode exposes only that tool.

  4. Add the UUID to the host configuration and restart. For example, replace the path and placeholders locally:

{
  "mcpServers": {
    "ynab": {
      "command": "uv",
      "args": ["run", "--frozen", "--directory", "/absolute/path/to/ynab-mcp", "ynab-mcp"],
      "env": {
        "YNAB_PAT": "<set locally; never commit>",
        "YNAB_PLAN_ID": "<plan UUID>",
        "YNAB_READ_ONLY": "true"
      }
    }
  }
}

The configured server exposes list_accounts, get_budget_summary, list_categories, list_transactions, get_spending_summary, and get_uncategorized_transactions. All are read-only tools. YNAB_READ_ONLY defaults to true; setting it to any other value fails startup. Logging is fixed at WARNING; setting LOG_LEVEL fails startup. If you no longer need access or suspect exposure, revoke the PAT in YNAB and remove it from your host configuration.

Related MCP server: Monarch Money MCP Server

What the results mean

  • Account balances and their on-budget, tracking, and combined totals are signed net balances, including liabilities. They are not spendable cash. Closed accounts are excluded by default; deleted accounts are always excluded.

  • available_in_categories sums non-deleted, non-internal month-category balances, including hidden categories. Ready to Assign is separate. YNAB's documented category schema has no stable credit-card-payment discriminator, so internal credit-card-payment balances may be omitted. This number is neither cash available nor the sum of account balances.

  • Spending is net expense-category outflows plus eligible uncategorized outflows on on-budget accounts; refunds reduce spending. Ordinary transfers between on-budget accounts, tracking-account postings, deleted rows, and Ready to Assign inflows are excluded. get_uncategorized_transactions shows actionable open-account outflows rather than every row lacking a category.

  • Dates are inclusive and the current month uses UTC. A current-month bucket is month-to-date; compare it with the same days in the previous month for equal coverage. For example, compare September 1–13 with August 1–13, rather than all of August. Clamp the prior end date to its last calendar day when needed.

  • Date ranges are limited to 366 days. Transaction tools return at most 500 rows, with truncated and complete flags; list_transactions omits memos unless include_memo=true. Aggregate tools require complete source data and return an error instead of a partial total when the bounded response cannot be processed. Money values are fixed-scale decimal strings in the plan currency.

Privacy boundary

The PAT itself is not provider-enforced read-only and can access any plan allowed by that token. The fixed plan UUID and GET-only routes constrain this server; they do not reduce the PAT's underlying permissions. The server has no YNAB write route, does not follow redirects, and does not take a caller-supplied URL. Its own no-persistence rule does not apply to your MCP host: financial results cross into the host and may enter its history or be sent to a remote model. Use a host whose data-handling policy you accept. Payee names, category names, and memos are untrusted data fields, not instructions to the assistant.

Verify this checkout

uv sync --frozen
uv run --frozen pytest
uv run --frozen ruff check .
uv run --frozen ruff format --check .
uv run --frozen mypy src
uv run --frozen pip-audit

The dependency audit is an explicit development/release check and may use the network. The running MCP server does not audit dependencies or phone home for that purpose. Tests use synthetic data and a fake PAT; no live YNAB account is needed.

Available Tools

1 tool
list_plansB
Read-only

List plan IDs and names for local setup.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior2/5

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

readOnlyHint=true already tells the agent this is a safe read, and the output schema documents the return shape. The description adds essentially nothing behavioral beyond restating the returned fields, so it carries no extra transparency.

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?

A single short sentence with zero waste and the resource front-loaded. It is efficient, though so terse that it borders on under-specification rather than tight conciseness.

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

Completeness3/5

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

With no parameters, an output schema, and a readOnlyHint, the definition is close to sufficient. However, it never clarifies what a 'plan' is or why the caller would need one for local setup, leaving a conceptual gap.

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 there is nothing to disambiguate and the baseline is 4. The description does not need to explain any argument semantics.

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 concrete verb (List) and the resource plus its returned fields (plan IDs and names). It is understandable in isolation, and there are no sibling tools to differentiate from, but the term 'plan' itself is never defined.

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

Usage Guidelines2/5

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

'For local setup' gestures at a context but gives no real when-to-use guidance, no prerequisites, and no when-not-to-use conditions. An agent gets a faint hint but must infer the actual trigger.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedlist_plans

TDQS

B3.2/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of confusion or overlap; the purpose of list_plans is entirely distinct.

Naming Consistency5/5

The sole tool follows a clean verb_noun snake_case convention, and no inconsistent patterns exist to violate.

Tool Count2/5

One tool is far too thin for a YNAB MCP server, which would naturally need to cover budgets, accounts, transactions, and categories.

Completeness1/5

Severely incomplete: it only lists plan IDs and names with no budget, account, transaction, category, or create/read operations beyond local setup.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Read-only MCP server for YNAB that provides tools for budgets, accounts, categories, transactions, and financial summaries via HTTP or stdio.
    1
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Read-only MCP and HTTP proxy server for accessing Monarch Money financial data, enabling transaction analysis, budget tracking, and cashflow insights through natural language.
    6
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Enables users to interact with YNAB budgets, accounts, transactions, and more through a comprehensive set of tools with batch operations, deterministic analysis, and undo support.
    26
    48 npm
    5
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Provides a read-only interface to YNAB budget data, allowing AI assistants to inspect budgets, accounts, categories, transactions, and more. Includes an experimental guarded write workflow for category assignments.
    10
    11 npm
    MIT