YNAB MCP Server

Export Transactions

export_transactions

Read-onlyIdempotent

Export filtered YNAB transactions as CSV text for spreadsheet or offline analysis, with safeguards to prevent formula injection.

Instructions

Export transactions as CSV text (same filters as get_transactions, including type). Columns: date, amount (dollars, negative = outflow), payee, category, account, memo, cleared, approved, transfer, id. Free-text columns (payee, category, account, memo) get a leading apostrophe when the value starts with a formula character (= + - @ tab CR), so spreadsheet applications cannot execute a bank-imported merchant string as a formula. Use when the user wants data for a spreadsheet or offline analysis; for programmatic work prefer get_transactions (structured JSON). Read-only. Large date ranges produce large output — narrow with filters when possible.

Input Schema

TableJSON Schema

Name	Required	Description
`type`	No	Filter by approval/categorization status (e.g. export the unapproved queue for offline review)
`month`	No	Filter by month (YYYY-MM-DD, first of month)
`maxRows`	No	Row cap (default 500, max 2000). When exceeded, the newest rows are kept and a second text block reports the truncation.
`payeeId`	No	Filter by payee ID
`budgetId`	No	Budget ID (uses default if not provided)
`accountId`	No	Filter by account ID
`sinceDate`	No	Only export transactions on or after this date (YYYY-MM-DD). If omitted, YNAB defaults to one year ago.
`untilDate`	No	Only export transactions on or before this date (YYYY-MM-DD)
`categoryId`	No	Filter by category ID

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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.6/5.0

Behavior5/5

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

Beyond annotations (read-only, idempotent, non-destructive), the description discloses several important behaviors: CSV column semantics ('negative = outflow'), formula-injection protection via leading apostrophe and why it exists, and a warning about large date ranges producing large output. The 'Read-only' line is redundant with annotations but does not contradict them.

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?

The description is efficiently structured, front-loading the core purpose and then adding column details, security rationale, usage guidance, and a size warning. The only mild redundancy is the standalone 'Read-only.' sentence, which duplicates the readOnlyHint annotation, so it does not receive a 5.

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

Completeness5/5

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

For a tool with 9 optional parameters, an output schema, and a non-trivial CSV formatting behavior, the description covers everything an agent needs to select and invoke it correctly: format, columns, amount sign convention, formula-injection safety, usage context, and scale warning. Nothing important 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%, so the schema carries the parameter documentation burden. The description adds a useful hint that filters are shared with get_transactions and highlights the 'type' filter, but it does not materially elaborate on individual parameters. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Export transactions as CSV text.' It also names the format and explicitly contrasts with get_transactions ('same filters as get_transactions'), making the tool's role unambiguous relative to its siblings.

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

Usage Guidelines5/5

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

Explicit when-to-use guidance is provided: 'Use when the user wants data for a spreadsheet or offline analysis; for programmatic work prefer get_transactions (structured JSON).' It also advises narrowing filters for large ranges, giving the agent actionable selection and invocation rules.

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