Loading ToolBench
YNAB MCP server demonstrates solid tool definition quality with consistent naming conventions, comprehensive parameter schemas using Zod, and detailed descriptions. All 18 tools follow verb_noun patterns (ynab_get_*, ynab_create_*, ynab_list_*, ynab_apply_*, ynab_move_*, ynab_approve_*, ynab_import_*, ynab_delete_*, ynab_auto_assign_). Schemas are explicit with type declarations and validation. However, output schemas are not formally documented in the tool definitions, error handling lacks actionable recovery guidance, and some parameter descriptions could be more specific about constraints and dependencies. The server accepts both IDs and human-friendly names (accountId/accountName, categoryId/categoryName, payeeId/payeeName), which improves usability. Dry-run and undo manifest patterns in apply_category_suggestions show mature error prevention thinking.
Applies explicitly supplied category suggestions after refetching and verifying every transaction fingerprint. Never auto-applies, approves, or calls TypeSafe. Supports dry-run and returns a pre-write undo manifest.
Approves an existing transaction in your YNAB plan.
Distributes Ready to Assign across categories whose monthly goal is not yet fully funded, largest shortfall first, until the money runs out. Set dryRun to see the plan without changing anything.
Approves multiple transactions at once. Provide an array of transaction IDs to approve them all in a single API call.
Income versus spending, month by month, so you can see whether you are running a surplus. Uses YNAB's own monthly totals rather than re-adding transactions.
Output schemas not formally documented. While input schemas use Zod with complete type definitions, no tool definition includes documentation of what fields are returned, their types, or how they should be used by downstream agents. This forces LLMs to infer output structure from execution or causes them to miss chaining opportunities.
Error handling lacks actionable recovery guidance. When tools fail (e.g., transaction refetch fails in apply_category_suggestions), errors are returned but do not guide the agent on next steps. Example: 'refetch_failed: Not Found' gives no hint whether to retry, validate IDs, or call a discovery tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 66 | - | v1 |
Creates a new transaction in your YNAB plan. The account can be given as accountId or accountName, and the category as categoryId or categoryName - names are fuzzy-matched against the plan. Either payeeId or payeeName must also be provided.
Deletes a transaction from the plan. This action cannot be undone.
Gets transactions from a plan with optional filters. Can filter by date range, account, category, payee, or approval status.
Gets every unapproved transaction in a plan, optionally limited to those on or after a given date.
Imports available transactions on all linked accounts for the plan. This triggers an import from connected financial institutions (equivalent to clicking 'Import' in the YNAB app).
Lists all accounts in a plan. Useful for finding account IDs when creating transactions.
Lists all categories in a plan, grouped by category group. Useful for finding category IDs when creating transactions or updating budgeted amounts.
Lists all plan months. Each month contains summary information about budgeting status.
Lists all payees in a plan. Useful for finding payee IDs when creating transactions.
Lists all available plans from YNAB API
Lists all scheduled (recurring) transactions in a plan.
Moves budgeted money from one category to another in a given month, typically to cover overspending. YNAB has no single move endpoint, so this reads both categories and rewrites their budgeted amounts; if the second write fails the response says exactly which half was applied.
Get a summary of the plan for a specific month highlighting overspent categories that need attention and categories with a positive balance that are doing well.
Pagination not consistently offered. get_transactions accepts a 'limit' parameter but provides no 'offset' or 'cursor' for pagination. List tools (list_accounts, list_payees, list_months) have no pagination at all. Large result sets will exceed context windows without pagination support.
Parameter constraints and dependencies not fully documented. For example, create_transaction accepts both accountId and accountName but does not explicitly state these are alternatives, only one is needed. Similarly, payeeId and payeeName are presented as optional without stating that at least one is required. Month parameters accept 'current' as a special value but this is not consistently documented across tools (auto_assign, move_money, plan_summary).
Destructive operations (delete_transaction) lack confirmation or dry-run support. While apply_category_suggestions offers dry-run and undo manifests, delete_transaction proceeds immediately with no confirmation mechanism. This violates the confirmation-request pattern for irreversible operations and increases risk of accidental data loss when an agent is asked to 'delete the wrong transaction' due to ambiguity.
Dual-naming deprecation not sunset. Both 'planId' and 'budgetId' are accepted in all tools, with planId being the canonical name. The server notes 'budgetId is a deprecated alias' but continues to accept it across all 18 tools. After a reasonable deprecation window (e.g., 6 months in production), budgetId should be removed entirely to reduce parameter confusion and teach LLMs the correct names.