YNAB MCP Server

Create account

create_account

Create a manually tracked YNAB account, such as cash or a savings account, without linking a bank. Set the account name, type, and starting balance.

Instructions

Create an account that the user tracks by hand, such as cash or a new savings account. The account is not connected to a bank.

Input Schema

Name	Required	Description
`name`	Yes	Account name (required)
`type`	Yes	Account type: "checking", "savings", "cash", "creditCard", "otherAsset", or "otherLiability" (required)
`balance`	Yes	Starting balance in currency units. Use a negative balance for money owed on a credit card or liability (required)

Output Schema

Name	Required	Description
`id`	Yes	Unique account identifier
`name`	Yes	User-defined account name
`note`	No	User-defined account notes
`type`	Yes	Account type. Common values: 'checking', 'savings', 'creditCard', 'cash', 'lineOfCredit', 'otherAsset', 'otherLiability', 'mortgage', 'autoLoan', 'studentLoan', 'personalLoan', 'medicalDebt', 'otherDebt'
`closed`	Yes	Whether this account has been closed
`balance`	Yes	Current balance in currency units
`on_budget`	Yes	Whether this account's money is part of the plan
`cleared_balance`	Yes	Balance of cleared transactions in currency units
`transfer_payee_id`	Yes	Payee to use on a transaction that transfers into this account
`uncleared_balance`	Yes	Balance of uncleared transactions in currency units
`last_reconciled_at`	No	When the account was last reconciled
`debt_escrow_amounts`	No	Escrow amounts by date for mortgage accounts. Keys are dates, values are escrow amounts in currency units
`debt_interest_rates`	No	Interest rates by date for debt accounts. Keys are dates, values are interest rates as decimals (e.g., 0.03375 for 3.375%)
`direct_import_linked`	No	Whether the account imports from a bank connection
`debt_minimum_payments`	No	Minimum payment amounts by date for debt accounts. Keys are dates, values are payment amounts in currency units
`direct_import_in_error`	No	Whether the bank connection needs the user's attention

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 26, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the write/safety profile is covered. The description adds the meaningful behavioral point that the created account has no bank link, but says nothing about duplicate-name handling, whether the account can later be linked, or what a non-idempotent repeat call does.

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, no filler, and the key scope constraint ('tracked by hand') appears before the clarifying 'not connected to a bank.' Every sentence earns its place.

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?

For a simple three-param creation tool with full schema coverage and an output schema, the description covers what is created and the manual-account scope. It is slightly thin on post-creation behavior (duplicates, visibility in list_accounts), but nothing essential to making the call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all three required parameters documented including the enum values for 'type' and the negative-balance convention for 'balance'. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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?

The description gives a specific verb and resource ('Create an account') and immediately scopes it to manually tracked accounts like cash or savings, with the clarifying constraint 'not connected to a bank.' It does not reference any sibling tool (e.g. list_accounts) to sharpen the boundary, so it stops short of full differentiation.

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

Usage Guidelines4/5

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

'Create an account that the user tracks by hand' plus 'not connected to a bank' effectively states the condition under which this tool applies and implicitly excludes synced bank accounts. No alternative tool or follow-up action (e.g. how to record transactions afterward) is named, so it is clear context rather than explicit alternatives.

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