Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_get_group_balances

Read-onlyIdempotent

Show each member's balance in one Splitwise group and who should pay whom to settle up, with per-currency amounts and the debt source.

Instructions

Show each member's balance in one group and who should pay whom to settle it.

Calls GET /get_group/{group_id} and renders the members' non-zero balances per currency, then the group's debts as From → To amount CUR (From owes To), with names resolved from the group's own members (an id not among them is shown as user N). Uses simplified_debts; when Splitwise returns none, falls back to original_debts and says so. Sign convention: positive = the member is owed by the group; negative = the member owes the group. Settled-up members are listed by name only. An amount that is not a plain decimal is shown raw and flagged (unparsed).

When to Use:

  • "Who owes whom in the Trip group?", "how do we settle up the apartment?".

  • Before recording a settle-up payment, to get the exact amounts and user ids.

When NOT to Use:

  • For your balances across all friends (use splitwise_get_balances).

  • For non-group expenses: group_id 0 is the non-group pseudo-group; /get_group/0 answers but lists only you as a member, so per-friend balances come from splitwise_get_balances, not from here.

  • For the group's details, invite link or membership changes (use splitwise_get_group, splitwise_add_user_to_group, splitwise_remove_user_from_group).

  • To find a group id from its name (use splitwise_resolve_group / splitwise_get_groups).

Returns: Markdown: a member table (First Last (id N) | +20.00 USD), the settled-up members, and the debts list with its source (simplified_debts or original_debts), capped at 50 rows each. JSON: {group: {id, name}, sign_convention, members: [raw members], debts_source: "simplified_debts" | "original_debts" | null, debts: [raw debts]}.

Examples:

  • params = {"group_id": 12345}

  • params = {"group_id": 12345, "response_format": "json"}

Error Handling: 403 means you are not a member of that group; 404 means the id is wrong or the group was deleted (splitwise_undelete_group restores it) — or, for group_id 0, that the pseudo-group is not served here (use splitwise_get_balances). Errors come back as an Error ... string.

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the sign convention (positive = owed by group), the simplified_debts → original_debts fallback and that it says so, the 50-row cap, raw-and-flagged behavior for unparseable amounts, and 403/404 error semantics. This is unusually rich behavioral disclosure.

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?

Well front-loaded and sectioned with headers, so the length is scannable rather than rambling. However, the detailed 'Returns' section partially restates content already available in the output schema, which is minor redundancy.

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?

Given the group/currency/settlement complexity, the description covers the sign convention, debt-source fallback, member-name resolution, error codes, and the pseudo-group trap. Combined with the existing output schema, an agent has everything needed to call and interpret this tool.

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 reported at 0%, so the description must carry the burden, and it does: it explains group_id 0 as the non-group pseudo-group whose only member is you, and what response_format 'markdown' vs 'json' returns. It also supplies concrete example param objects.

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+resource with scope ('each member's balance in one group and who should pay whom to settle it'), and explicitly distinguishes itself from splitwise_get_balances, splitwise_get_group, and the group-mutation siblings. An agent can pick this tool without opening another 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?

Has dedicated 'When to Use' and 'When NOT to Use' sections naming concrete alternatives (splitwise_get_balances for all-friend balances, splitwise_get_group for details, splitwise_resolve_group for id lookup) and an explicit edge case (group_id 0 pseudo-group returning only you). Nothing is left to inference.

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