moneylover-mcp

Delete transaction

moneylover_delete_transaction

DestructiveIdempotent

Permanently delete a confirmed existing transaction using its id, wallet, and date; preview with dry_run first, and use the update action instead to correct details.

Instructions

Permanently delete one existing transaction. Use it only when the user asked for the removal in their own words, after identifying the entry with moneylover_list_transactions (which supplies the id, wallet and date) and showing it to the user to confirm; dry_run returns that entry without deleting it. To fix a wrong detail use moneylover_update_transaction instead. Behavior: there is no undo through this server. id, wallet and date must come from the same moneylover_list_transactions row: Money Lover cannot look up by id alone, so the wallet is searched one day either side of date, and a mismatch reports the transaction as not found. Transfers, debts, loans and their repayments are refused because they are linked to other transactions; delete those in the Money Lover app. The same limits as moneylover_add_transaction apply: writes are off unless MONEYLOVER_ALLOW_WRITE=true, the wallet allowlist and hourly write limit, and the transaction's date must fall within 366 days back to 31 days ahead. A failure reported as UNCERTAIN means the transaction may or may not have been deleted: check moneylover_list_transactions before retrying.

Input Schema

Name	Required	Description
`id`	Yes	Id of the transaction, exactly as returned by moneylover_list_transactions.
`date`	Yes	The transaction's date as YYYY-MM-DD, exactly as returned by moneylover_list_transactions. Used to find it.
`wallet`	Yes	Name of the wallet the transaction is in, exactly as returned by moneylover_list_transactions.
`dry_run`	No	If true, find the transaction and run every check, but do not delete it.

Output Schema

Name	Required	Description
`deleted`	Yes	True only if the transaction was really deleted.
`dry_run`	Yes	True when nothing was sent to Money Lover.
`transaction`	Yes	The transaction that was (or, for a dry run, would be) deleted.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Oct 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 destructiveHint/idempotentHint annotations: it discloses there is no undo, why id+wallet+date must come from the same row, the one-day-either-side wallet search that can produce false 'not found', which transaction types are refused (transfers, debts, loans), the write gating env var, allowlist, hourly limit and date window, and how to interpret UNCERTAIN failures. This is exactly the context annotations cannot carry.

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-loads the core action and the usage gate, then groups behavior into a compact block. It is dense and mostly earned, though the write-limits sentence is long enough to be scanned past.

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, full annotation coverage and 100% schema descriptions, the remaining burden is behavioral guidance, and the description covers failure modes, refusal cases and confirmation requirements. An agent has everything needed to call this correctly or decline.

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%, but the description still adds real meaning: the three identifiers must come from one moneylover_list_transactions row and why (Money Lover cannot look up by id alone), and dry_run runs all checks without deleting. The rationale is valuable even though the field-level docs already exist.

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 with the key qualifier 'permanently,' so an agent immediately knows this is an irreversible single-record deletion. It contrasts itself with moneylover_update_transaction, making the boundary against a sibling explicit.

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 an explicit precondition ('only when the user asked for the removal in their own words'), a required identification-and-confirmation workflow via moneylover_list_transactions, and names the alternative tool for the adjacent intent of fixing a wrong detail. The dry_run escape hatch is also explained.

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

Deploy Server