Monarch Money MCP Server

Overview Schema Source Related Servers Discussions Admin

Bulk Update Transactions

update_transactions_bulk

Idempotent

Update multiple transactions in a single batch, returning per-item results and counts. Apply field changes individually without failing the entire batch.

Instructions

Update transactions concurrently, returning per-item results and counts.

Args: updates: JSON array encoded as a string. Each item requires a nonempty transaction_id and accepts amount, merchant_name, category_id, date (YYYY-MM-DD), notes, goal_id, hide_from_reports, needs_review, and owner_user_id. Fields have the same meaning as update_transaction; omitted/null fields stay unchanged. Empty notes or goal_id clears that value; empty owner_user_id makes the transaction Shared.

Items reject unknown fields and wrong types without coercion; amounts must be finite numbers and flags must be booleans. Invalid items fail individually; valid items still run. The batch is not atomic and does not roll back successes.

Example: [{"transaction_id": "txn_123", "category_id": "cat_456", "notes": ""}, {"transaction_id": "txn_789", "needs_review": false}]

Input Schema

TableJSON Schema

Name	Required	Description	Default
`updates`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`message`	No
`results`	Yes
`summary`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2May 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral detail: invalid items fail individually while valid items run, the batch is not atomic and does not roll back, unknown fields/wrong types are rejected, and empty notes/goal_id clear values while empty owner_user_id reassigns to Shared. This far exceeds the annotation baseline.

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 well-structured: a one-sentence summary, a detailed Args specification, validation/atomicity caveats, and an example. Every sentence adds necessary information for correct invocation, and the length is justified by the tool's complex payload.

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?

Given the single parameter's complexity, the description covers payload schema, field semantics, validation behavior, failure isolation, concurrency, and return shape ('per-item results and counts'). The presence of an output schema means return details do not need to be restated, so the description is complete.

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?

The input schema gives the updates parameter no description at all (0% coverage). The description fully compensates by specifying the JSON-array-as-string format, required transaction_id, all accepted fields, date format, type constraints, clearing semantics, and a concrete example.

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: 'Update transactions concurrently, returning per-item results and counts.' It clearly distinguishes this bulk operation from single-transaction siblings like update_transaction by emphasizing concurrency and per-item results.

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?

The bulk/concurrent nature and the bulk name imply this is for multiple transactions, and it references update_transaction for field semantics. However, it never explicitly says when to prefer this tool over update_transaction or when not to use it, leaving the usage decision mostly to inference.

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