MCP Server for YNAB

Overview Schema Source Related Servers Discussions Admin

Triage — Pending imports

triage_pending_imports

Read-only

Find YNAB-imported card holds that never posted as real charges, so you can review and delete stale pending authorizations inflating account balances.

Instructions

[READ] Card authorisations YNAB imported that never became real charges. A merchant's hold — a fuel pump, a hotel, a rideshare — arrives through direct import as a transaction with an import_id starting 'YNAB:P:'. When the real charge posts, usually at a different amount, it comes in as its own transaction and the hold is left behind: uncleared, permanent, and counted in the card's balance. Four of them were inflating one card by about $79 on the plan this was written for. triage_unmatched_manual cannot find these — it looks for entries with no import_id, and these have one. account_id narrows it to one account. older_than_days is how long a hold must have sat (default 7). since_date bounds how far back to read (default 6 months). Check each against the statement before deleting: a hold whose charge did post appears twice, and only the hold should go. Costs two requests.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`plan_id`	No
`account_id`	No
`since_date`	No
`older_than_days`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Sep 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/destructiveHint annotations by explaining the lifecycle that produces these leftovers (uncleared, permanent, counted in the card's balance), the identifiable marker prefix, a real-world impact example, and the cost profile ('Costs two requests').

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?

Front-loaded with the essential identifier and definition, then parameters, then the caveat — a sound order. The anecdotal detail about $79 across four holds is illustrative but the longest non-essential sentence.

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, return values need no explanation, and the description covers definition, distinguishing marker, sibling exclusion, parameter meanings, defaults, prerequisite verification, and request cost. Nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema description coverage is 0%, so the description carries the burden and it largely does: account_id scopes to one account, older_than_days is the hold-age threshold (default 7), since_date bounds the read window (default 6 months). plan_id is left unexplained, which is the only gap.

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 and resource: card authorisations imported by YNAB that never became real charges, marked [READ] and identified by the 'YNAB:P:' import_id prefix. It explicitly distinguishes itself from the sibling triage_unmatched_manual and explains why that tool cannot find these entries.

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?

Names the alternative (triage_unmatched_manual) with the exact reason it fails here, and gives operational guidance: check each hold against the statement before deleting, since a posted charge appears twice and only the hold should be removed. Defaults for older_than_days and since_date are also given.

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

Deploy Server