Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_get_group

Read-onlyIdempotent

Read one Splitwise group's members with balances, who owes whom, and invite link. Use it before settling up or to get a member's user ID.

Instructions

Read one group: its members with balances, who owes whom, and the invite link.

Calls GET /get_group/{id}. Members are rendered First Last (id N) with every non-zero balance per currency. Debts are rendered A → B 12.50 USD (A owes B), names resolved from the group's own members; the simplified debts are shown, or the original debts (labelled as such) when Splitwise returned no simplified ones. Sign convention for member balances: positive = that member is owed money; negative = they owe. Group id 0 is the pseudo-group for non-group expenses.

When to Use:

  • To see who owes whom inside a group before settling up.

  • To get a member's user id before removing them or building expense shares.

  • To fetch the group's invite link.

When NOT to Use:

  • To list all your groups (use splitwise_get_groups), or find one by name (splitwise_resolve_group).

  • For the group's expenses (use splitwise_get_expenses with group_id).

Returns: A markdown block (name, type, settings, members, debts, invite link; members and debts capped at 50 each, with a note) or, with response_format=json, the raw group object.

Examples:

  • params = {"group_id": 12345}

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

Error Handling: 403 → you are not a member of that group; 404 → wrong id or the group was deleted (see splitwise_undelete_group).

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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial non-obvious behavior: member/debt rendering formats, the balance sign convention, fallback from simplified to original debts, 50-item caps with a note, and 403/404 error semantics. This is well beyond what the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but highly structured and front-loaded: one-line purpose first, then endpoint/format details, then When to Use / When NOT to Use, Returns, Examples, Error Handling. Every section carries call-relevant information; no filler sentences.

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?

Despite an output schema existing, the description still specifies return shape (markdown block contents, caps, JSON alternative), gives concrete call examples, and documents the two likely error codes with remediation. Nothing an agent needs to invoke this correctly 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?

The schema gives minimal per-parameter prose (coverage reported at 0%), but the description clarifies group id 0 as the non-group-expenses pseudo-group and explains that response_format=json returns the raw group object versus default markdown. It adds real meaning, though response_format is partly a restatement of the enum.

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?

Opens with a specific verb+resource+scope: 'Read one group: its members with balances, who owes whom, and the invite link.' It also names the underlying endpoint (GET /get_group/{id}) and explicitly distinguishes itself from splitwise_get_groups, splitwise_resolve_group, and splitwise_get_expenses, so an agent can route correctly 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?

Contains dedicated 'When to Use' and 'When NOT to Use' sections with named alternatives for each exclusion (splitwise_get_groups for listing, splitwise_resolve_group for name lookup, splitwise_get_expenses with group_id for expenses). The selection logic is fully explicit.

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