YNAB MCP Server

Audit Account Reconciliation

audit_account_reconciliation

Read-onlyIdempotent

Identify reconciliation gaps by reviewing last-reconciled dates and cleared balances for all open accounts. Optionally inspect uncleared transactions since last reconciliation to match bank statement.

Instructions

Read-only reconciliation diagnosis. Without accountId: summarizes every open account's last-reconciled date and cleared/uncleared balances (one API request). With accountId: additionally lists that account's uncleared and unapproved transactions since the last reconciliation, which are exactly the rows to compare against the bank statement. Makes no changes — actual reconciliation (marking transactions reconciled and locking the balance) happens in the YNAB UI; use this to find what needs attention first. Interpretation note: an old last_reconciled_at is not itself a problem if cleared_balance matches the bank; uncleared transactions older than a few days are the usual culprits.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`budgetId`	No	Budget ID (uses default if not provided)
`accountId`	No	Account to inspect in detail (adds that account's uncleared/unapproved transaction list)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv5.4.0Sep 15, 2026
- removedOutput schema / properties / result / description
```
Removed value: -"Structured result returned by Audit Account Reconciliation."
```
Addedv5.2.0Aug 29, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds specifics: it performs a single API request without accountId, lists uncleared/unapproved transactions with accountId, and helps compare against the bank statement. This is valuable behavioral context beyond the annotations, and it reinforces the read-only promise by stating 'Makes no changes.' No contradiction.

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?

The description is front-loaded with the core purpose and the parameter-dependent behavior, and each subsequent sentence earns its place by covering usage and interpretation. Despite its length, there is no redundancy or filler; the structure mirrors the decision process an agent would follow.

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?

With an output schema present, the return format is covered. The description fully explains what the tool does, when to use it, how to interpret results, and what it does not do (actual reconciliation). Nothing an agent needs to call this correctly and interpret the result is missing.

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

Parameters5/5

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

Schema coverage is 100% for both parameters, but the description adds crucial semantics: it explains how the presence or absence of accountId changes the tool's behavior (summary vs. detail listing). This goes far beyond the schema's bare field descriptions and directly informs the agent which parameter to set for the desired outcome.

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 precise verb and resource ('Read-only reconciliation diagnosis') and then distinguishes two modes (with/without accountId) that map cleanly to the two parameters. It clearly separates this tool from siblings like audit_credit_card_payments by focusing on reconciliation state rather than card payment issues.

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?

Explicitly states when to use it ('use this to find what needs attention first') and when not to (actual reconciliation happens in the YNAB UI). It also provides an interpretation note that helps the agent decide if a finding is actionable, which is exactly the kind of usage guidance that reduces mis-calls.

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