YNAB MCP Server

Bulk Approve Transactions

ynab_bulk_approve_transactions

Idempotent

Approves (or, with approved: false, un-approves) one or more transactions in a single API call.

Instructions

Approves (or, with approved: false, un-approves) one or more transactions in a single API call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "transactionIds": "<transactionIds>"
    },
    "name": "ynab_bulk_approve_transactions"
  }
}

Input Schema

Name	Required	Description
`planId`	No	The plan ID (optional, defaults to YNAB_PLAN_ID; budgetId is a deprecated alias)
`approved`	No	Whether the transactions should be marked as approved (default true); false un-approves them
`budgetId`	No	Deprecated alias of planId (still accepted)
`transactionIds`	Yes	Array of transaction IDs to approve

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.0Oct 22, 2026

addedInput schema / properties / approved

Added value: +{
+  "anyOf": [
+    {
+      "default": true,
+      "description": "Whether the transactions should be marked as approved (default true); false un-approves them",
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Whether the transactions should be marked as approved (default true); false un-approves them"
+}

Changed7 schema fields changedv0.3.0Sep 22, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / budgetId / anyOf

Added value: +[
+  {
+    "description": "Deprecated alias of planId (still accepted)",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / budgetId / description

Previous value: -"The ID of the budget (optional, defaults to YNAB_BUDGET_ID environment variable)"New value: +"Deprecated alias of planId (still accepted)"

removedInput schema / properties / budgetId / type
```
Removed value: -"string"
```

addedInput schema / properties / planId

Added value: +{
+  "anyOf": [
+    {
+      "description": "The plan ID (optional, defaults to YNAB_PLAN_ID; budgetId is a deprecated alias)",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The plan ID (optional, defaults to YNAB_PLAN_ID; budgetId is a deprecated alias)"
+}

addedInput schema / properties / transactionIds / maxItems
```
Added value: +500
```
addedInput schema / properties / transactionIds / minItems
```
Added value: +1
```

Addedv1.0.0Jan 2, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description only needs to add context. It usefully discloses that approvals are reversible via approved: false, but says nothing about partial failures in a bulk call, the 500-item cap, or the API/rate-limit cost of a single batched request.

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?

One sentence, zero filler, and the most decision-relevant bit (the un-approve capability) is parenthetically front-loaded.

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

Completeness3/5

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

No output schema exists, so the description should ideally say what a bulk call returns on success or partial failure. With annotations and full schema coverage the core call is answerable, but an agent writing a mutation over up to 500 IDs is left guessing about error semantics.

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% and every parameter (planId, budgetId alias, approved, transactionIds) is documented in the schema itself. The description only restates the approved:false behavior, adding no syntax or ordering information beyond the schema, which is the baseline-3 case.

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

Purpose4/5

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

States a specific verb (Approves / un-approves) and resource (one or more transactions) plus the key batching trait 'in a single API call'. That implicitly distinguishes it from the singular ynab_approve_transaction sibling, but it never names that sibling, so the differentiation is left to inference.

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

Usage Guidelines3/5

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

There is no explicit 'use this when... use X instead when...' guidance. The bulk phrasing implies it should be preferred over ynab_approve_transaction for multiple IDs, but the agent has to derive that from 'one or more' rather than being told.

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