ofw_update_expense
Update an existing OurFamilyWizard expense — amount, date, payer, title, children, or receipts — while preserving every field you don't pass.
Instructions
Change an existing OurFamilyWizard expense. Pass expenseId plus ONLY the fields you want to change; every field you omit keeps its current value. The tool reads the expense from OFW first and sends the merged result, because OFW's update replaces the whole expense and a field left out would otherwise be erased. If a field you did not pass cannot be read back from OFW, the update is refused as EXPENSE_FIELDS_UNREADABLE and names the field; pass it explicitly (description:null or receiptFileId:null to send none). receiptFileId REPLACES all current receipts; omit it to keep them. Set privateExpense=false to publish a private expense to the co-parent. The confirmation is bound to the expense exactly as read, so if it changes on OFW in between, the update is refused instead of overwriting that change. If the request fails without a definitive answer the result is EXPENSE_UNCONFIRMED: the update may already have been applied, so check ofw_list_expenses before retrying. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call performs NO write and returns a preview of exactly what would happen plus a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New title (omit to keep) | |
| amount | No | New full expense amount (omit to keep) | |
| payerId | No | New payer: the userId of the parent who owes (omit to keep) | |
| children | No | New child userIds, replacing the current list (omit to keep) | |
| expenseId | Yes | Existing OFW expense entity id | |
| categoryId | No | New OFW expense category id (omit to keep) | |
| description | No | New description; null removes it (omit to keep) | |
| confirmToken | No | ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation. | |
| purchaseDate | No | New expense date, YYYY-MM-DD (omit to keep) | |
| receiptFileId | No | Receipt fileId that REPLACES all current receipts; null removes them (omit to keep) | |
| privateExpense | No | true = visible only to you; false = shared with the co-parent (omit to keep) |