moneylover-mcp

update_transaction

DestructiveIdempotent

Correct an existing Money Lover transaction by changing its category, amount, note, or date; omitted fields stay unchanged.

Instructions

Correct an existing transaction: change its category, amount, note or date; fields left out keep their current value. Use it only when the user asked for the correction in their own words, after identifying the entry with list_transactions (which supplies the id, wallet and date). To remove an entry use delete_transaction; to record a new one use add_transaction. Use dry_run to preview the before/after while details are unsettled. Behavior: the transaction stays in its wallet; to move it to another wallet, delete it and add it again. Photo, location, event, people and the 'exclude from report' flag are kept as they are. Transfers, debts, loans and their repayments are refused because they are linked to other transactions; change those in the Money Lover app. The same limits as add_transaction apply: writes are off unless MONEYLOVER_ALLOW_WRITE=true, the wallet allowlist, maximum amount and hourly write limit, and both the current and the new date must be within roughly the last year to a month ahead. Repeating the same call changes nothing further. A failure reported as UNCERTAIN means the change may or may not have been saved: check list_transactions before retrying.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Id of the transaction, exactly as returned by list_transactions.
`date`	Yes	The transaction's current date as YYYY-MM-DD, exactly as returned by list_transactions. Used to find it; to move it to another day use new_date.
`note`	No	New note, replacing the old one entirely. Pass "" to clear it; omit to keep it.
`type`	No	"income" or "expense". Only used with category, when that name exists as both.
`amount`	No	New positive amount in the wallet's currency, e.g. 50000 or "12.50". Omit to keep the current amount.
`wallet`	Yes	Name of the wallet the transaction is in, exactly as returned by list_transactions.
`dry_run`	No	If true, find the transaction and validate the change, but do not save it.
`category`	No	New category name as returned by list_categories for the transaction's wallet. Sub-categories may be written as "Parent > Child". Omit to keep the current category.
`new_date`	No	New date as YYYY-MM-DD. Omit to keep the current date.

Output Schema

TableJSON Schema

Name	Required	Description
`after`	Yes	The transaction as it is (or, for a dry run, would be) after this call.
`before`	Yes	The transaction as it was before this call.
`dry_run`	Yes	True when nothing was sent to Money Lover.
`updated`	Yes	True only if the change was really saved.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 18, 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 annotations: it discloses preserved fields (photo, location, event, people, exclude flag), the wallet-immutability rule, refusals for transfers/debts/loans, write gating via MONEYLOVER_ALLOW_WRITE, allowlist/amount/rate limits, the date window, and the UNCERTAIN failure semantics. The statement that repeating a call changes nothing corroborates idempotentHint=true rather than contradicting it.

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 purpose, then constraints, then alternatives and edge cases in a logical order; virtually every sentence carries information an agent needs. It is a dense paragraph rather than scannable structure, which costs it the top mark but there is little waste.

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?

For a 9-parameter mutation tool with an output schema already defined, the description covers the remaining burden: preconditions, write gating, refusal cases, idempotency, and the ambiguous-failure recovery path. Nothing an agent needs to call it safely 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that wallet cannot be changed here (delete and re-add instead) and that date is a lookup key while new_date performs the move. The type-parameter nuance duplicates the schema text, so it is not a full 5.

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 ('Correct an existing transaction') and immediately scopes it to a partial update ('fields left out keep their current value'). It explicitly distinguishes itself from siblings delete_transaction and add_transaction, so an agent can route without opening any schema.

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?

Gives explicit when-to-use ('only when the user asked for the correction in their own words'), a prerequisite ('after identifying the entry with list_transactions'), and named alternatives for the adjacent operations (remove → delete_transaction, create → add_transaction). dry_run is also framed as the correct choice when details are unsettled.

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

Deploy Server