Monarch Money MCP Server

Overview Schema Source Related Servers Discussions Admin

Update Transaction Splits

update_transaction_splits

Idempotent

Replace a transaction's entire split set or remove all splits by passing an empty list. Split amounts must sum to the parent amount for Monarch to accept the update.

Instructions

Replace a transaction's entire set of splits, or remove all splits with [].

Args: transaction_id: Parent transaction ID. For a split leg from list/search, resolve parent_transaction_id with get_transaction_details first. splits: Complete replacement list. Each leg accepts: - amount (required): Negative for expenses, positive for income. Amounts must sum to the parent's amount or Monarch rejects the update. - category_id: Category ID for the leg. - merchant_name: Display name; defaults to the parent merchant. - notes: Per-leg memo.

Example for a -100.00 parent transaction: [{"amount": -70.00, "category_id": "cat_groceries", "notes": "Food"}, {"amount": -30.00, "category_id": "cat_household"}]

Returns transaction_id, has_split_transactions, resulting splits, and a summary.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`splits`	Yes
`transaction_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`splits`	Yes
`message`	Yes
`transaction_id`	Yes
`has_split_transactions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.0Sep 24, 2026

changedInput schema / $defs / TransactionSplit / description

Previous value: -"One leg of a split transaction.\n\nThe split amounts must sum to the parent transaction's amount (Monarch\nvalidates this and rejects the update otherwise). Amounts keep the parent's\nsign convention — expenses are negative, income positive."New value: +"One leg of a split transaction.\n\nMonarch requires split amounts to sum to the parent amount, using the parent's\nsign convention: negative expenses, positive income."

Addedv0.4.0Jul 6, 2026

TDQS

B3.4/5.0

Behavior1/5

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

The description says the tool can 'remove all splits with []' and replaces the entire set of splits, which is a destructive operation on existing split data. The annotations declare destructiveHint=false, directly contradicting this behavior. Under the scoring rules, this is an Annotation Contradiction, forcing the lowest score despite the description's otherwise rich behavioral detail.

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?

The description is front-loaded with the core operation, then uses structured Args and Example sections. It is moderately long but every sentence carries useful information for a complex mutation tool. Minor verbosity in restating return values that the output schema already covers.

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

Completeness4/5

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

An output schema exists, so the description need not explain return values, though it does. It fully covers parameter semantics, validation constraints, and an example. The only notable gap is lack of guidance on when to use this tool versus update_transaction or update_transactions_bulk.

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 description coverage is 0% at the top level, so the description must compensate. It thoroughly explains transaction_id (parent transaction ID, with resolution guidance), and each split leg field: amount sign convention and sum requirement, category_id, merchant_name default, and notes. It also provides a concrete example, adding substantial meaning beyond the raw schema.

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?

The description states a specific verb and resource: replace a transaction's entire set of splits or remove all splits. It distinguishes itself from get_transaction_splits by being a mutation, but does not explicitly differentiate from update_transaction or other sibling update tools. An agent can identify the operation, but sibling routing 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?

The description gives some operational guidance: resolve parent_transaction_id via get_transaction_details when starting from a split leg, and amounts must sum to the parent's amount. However, there is no explicit when-to-use guidance versus update_transaction or update_transactions_bulk, nor any when-not conditions. Usage is implied by the operation semantics.

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