YNAB MCP server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@YNAB MCP serverhow much did I spend this month?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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
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
.envautomatically..env.examplecontains placeholders only;.envis ignored by Git.In this audited checkout, run
uv sync --frozen.Set
YNAB_PATbut leaveYNAB_PLAN_IDunset, then start the server and calllist_plansto find your plan UUID. Setup mode exposes only that tool.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_categoriessums 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_transactionsshows 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
truncatedandcompleteflags;list_transactionsomits memos unlessinclude_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-auditThe 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 toollist_plansBRead-only
List plan IDs and names for local setup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.1.0- First observed
list_plans
TDQS
Scored across 1 tool
With only a single tool, there is no possibility of confusion or overlap; the purpose of list_plans is entirely distinct.
The sole tool follows a clean verb_noun snake_case convention, and no inconsistent patterns exist to violate.
One tool is far too thin for a YNAB MCP server, which would naturally need to cover budgets, accounts, transactions, and categories.
Severely incomplete: it only lists plan IDs and names with no budget, account, transaction, category, or create/read operations beyond local setup.
Maintenance
Related MCP Connectors
Read-only access to your net worth, wealth percentile, projections, splits and budget.
Read-only Lunch Money accounts, transactions, categories and budgets. Unofficial connector.
Read your accounts, budgets and net worth, and draft changes you confirm.
Read-only bank & investment accounts via Plaid: balances, holdings, transactions, SQL analytics.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceRead-only MCP server for YNAB that provides tools for budgets, accounts, categories, transactions, and financial summaries via HTTP or stdio.1MIT
- AlicenseAqualityDmaintenanceRead-only MCP and HTTP proxy server for accessing Monarch Money financial data, enabling transaction analysis, budget tracking, and cashflow insights through natural language.6MIT
- AlicenseAqualityBmaintenanceEnables users to interact with YNAB budgets, accounts, transactions, and more through a comprehensive set of tools with batch operations, deterministic analysis, and undo support.2648 npm5MIT
- AlicenseAqualityBmaintenanceProvides 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.1011 npmMIT