Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_update_expense

Idempotent

Update an existing Splitwise expense by sending only the fields you want to change. Use it to fix details, date, category, currency, cost, or split, and to move an expense to another group.

Instructions

Change an existing expense — only the fields given are sent.

Calls POST /update_expense/{id}. Refused with Error: … writes are disabled unless SPLITWISE_ALLOW_WRITES=1 (enforced by the server's client).

WARNING: shares REPLACES ALL existing shares. Splitwise treats any users__* key as the complete new split, so list EVERY participant with their paid_share and owed_share — sending only the person who changed drops everyone else from the expense. Read the current split first with splitwise_get_expense.

No undo tool — to revert, re-send the previous values read with splitwise_get_expense first.

When shares is given, Σ paid_share and Σ owed_share must each equal the cost: the new cost if you pass one, otherwise the expense's current cost (read once with GET /get_expense/{id}). A mismatch is refused before the update is sent. Changing cost WITHOUT shares leaves the split to Splitwise, which may reject it if the current shares no longer add up — pass both to be explicit.

When to Use:

  • Fix a description, date, category or currency.

  • Change the amount together with the full new split.

  • Move an expense to another group (group_id; 0 = no group).

When NOT to Use:

  • To create a new expense (use splitwise_create_expense).

  • To delete or restore one (use splitwise_delete_expense / splitwise_undelete_expense).

  • To look up ids by name (use splitwise_resolve_friend / splitwise_resolve_group / splitwise_resolve_category).

Returns: A confirmation echoing Splitwise's response: the literal errors value and the expense as returned (id, description, cost, group, date, shares).

Examples:

  • params = {"expense_id": 3456789012, "description": "Dinner (incl. tip)"}

  • params = {"expense_id": 3456789012, "cost": "60.00", "shares": [ {"user_id": 491923, "paid_share": "60.00", "owed_share": "30.00"}, {"user_id": 678, "paid_share": "0.00", "owed_share": "30.00"}]}

Error Handling: Refused locally (nothing sent) when no field is given, when shares do not add up, or a share has both/neither identity. Splitwise answers 200 even on failure — the client turns a non-empty errors into Error: Splitwise rejected the request…; if that body still carried an expense object the error adds "Splitwise still returned N expense object(s) … may have landed", so read the expense back before retrying. 404 → wrong id; 403 → not your expense.

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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 the SPLITWISE_ALLOW_WRITES=1 write gate, that shares REPLACES the whole split and silently drops omitted participants, the no-undo requirement to re-read and re-send, and the trap that Splitwise returns HTTP 200 even on failure so a non-empty 'errors' body must be inspected. Annotations only say readOnly=false, idempotent=true, destructive=false; the description supplies the operational consequences those hints do not.

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 behaviour and the shares warning, then organises the rest under headers (When to Use / When NOT to Use / Returns / Examples / Error Handling). It is long, and the shares-replacement warning is repeated in both the body and the shares paragraph, but the redundancy is on the highest-risk failure mode and every section carries distinct information.

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 stateful mutation tool with a nested share sub-object, it covers the write gate, replacement semantics, arithmetic constraints, confirmation payload, worked examples, and a full error taxonomy (refused-local, 200-with-errors, 404 wrong id, 403 not your expense, possibly-landed writes). Nothing an agent needs before or after calling it 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?

Adds cross-field meaning the schema cannot express: Σ paid_share and Σ owed_share must each equal the new cost (or the current cost if cost is omitted), that a mismatch is refused before sending, and that changing cost without shares defers the split to Splitwise. group_id 0 = no group is also clarified. Some of the shares warning duplicates the schema's own field description, which is why this is not a 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 the specific verb and resource ('Change an existing expense'), the endpoint it calls, and the partial-update semantics ('only the fields given are sent'). It also names sibling tools for adjacent operations (create/delete/undelete/resolve), so an agent can distinguish it from every neighbouring write tool.

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?

Provides explicit 'When to Use' and 'When NOT to Use' lists that map each alternative (create_expense, delete_expense, undelete_expense, resolve_*) to the case that should select it. The prerequisite for safe share edits (read the current split with splitwise_get_expense first) is stated up front, not left to inference.

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