YNAB MCP Server

Export Transactions

export_transactions

Read-onlyIdempotent

Export filtered YNAB transactions to a spreadsheet-safe CSV with date, amount, payee, category, account, memo, cleared, approved, transfer, and ID; narrow date ranges to control output size.

Instructions

Export filtered CSV: date, dollar amount (negative outflow), payee, category, account, memo, cleared, approved, transfer, id. Formula-leading free text gets an apostrophe for spreadsheet safety. Narrow date ranges to limit output; prefer get_transactions for JSON.

Input Schema

Name	Required	Description
`type`	No	Approval/categorization filter.
`month`	No	Filter by month (YYYY-MM-DD, first of month)
`maxRows`	No	Row cap (default 500, max 2000); keeps newest rows and reports truncation in second text block.
`payeeId`	No	Filter by payee ID
`budgetId`	No
`accountId`	No	Filter by account ID
`sinceDate`	No	From YYYY-MM-DD, inclusive; default one year ago.
`untilDate`	No	Through YYYY-MM-DD, inclusive
`categoryId`	No	Filter by category ID

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv6.1.0Oct 25, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / properties / budgetId / description

Removed value: -"Budget ID (uses default if not provided)"

changedInput schema / properties / maxRows / description

Previous value: -"Row cap (default 500, max 2000). When exceeded, the newest rows are kept and a second text block reports the truncation."New value: +"Row cap (default 500, max 2000); keeps newest rows and reports truncation in second text block."

changedInput schema / properties / sinceDate / description

Previous value: -"Only export transactions on or after this date (YYYY-MM-DD). If omitted, YNAB defaults to one year ago."New value: +"From YYYY-MM-DD, inclusive; default one year ago."

changedInput schema / properties / type / description

Previous value: -"Filter by approval/categorization status (e.g. export the unapproved queue for offline review)"New value: +"Approval/categorization filter."

changedInput schema / properties / untilDate / description

Previous value: -"Only export transactions on or before this date (YYYY-MM-DD)"New value: +"Through YYYY-MM-DD, inclusive"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed2 schema fields changedv5.4.0Sep 15, 2026

addedInput schema / properties / maxRows

Added value: +{
+  "description": "Row cap (default 500, max 2000). When exceeded, the newest rows are kept and a second text block reports the truncation.",
+  "maximum": 2000,
+  "minimum": 1,
+  "type": "integer"
+}

removedOutput schema / properties / result / description

Removed value: -"Structured result returned by Export Transactions."

Addedv5.2.0Aug 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds real behavior: CSV formula-injection defense (apostrophe prefix on formula-leading text) and row-cap truncation semantics. It omits auth requirements and any server-side limits beyond maxRows, so it stops short of full disclosure.

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?

Three dense sentences with the output format and column list front-loaded, followed by safety notes and the routing hint. Every clause carries information an agent would otherwise have to infer.

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?

With an output schema present, the description need not explain return values, and it still sketches the CSV shape, sanitization, and truncation behavior. The only gap is the undocumented budgetId filter, a minor omission for an all-optional-parameter export tool.

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 coverage is 89% and the schema already documents type, month, maxRows, date filters with defaults and truncation reporting. The description adds only the amount-sign convention and a nudge toward narrowing dates; it says nothing about budgetId, the one parameter lacking a schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Export filtered CSV') and enumerates the exact output columns, including the sign convention for amounts. It also explicitly contrasts itself with get_transactions, so an agent can distinguish it from the JSON-based sibling without reading the schema.

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?

'prefer get_transactions for JSON' names the alternative and the condition that selects it, and 'Narrow date ranges to limit output' advises on scope. It does not state outright exclusions (e.g., when not to export at all), which keeps it short of a 5.

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

Deploy Server