Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_get_groups

Read-onlyIdempotent

List all Splitwise groups you belong to, including member counts and balances per currency, to find a group ID or review where you owe or are owed money.

Instructions

List every group you belong to, with members count and balances per currency.

Calls GET /get_groups and renders one row per group: name, id, type, number of members and the balance column. With current_user_id the column is YOUR balance in that group; without it, members' non-zero balances are listed compactly (at most 6 per group — splitwise_get_group has the rest). Group id 0 is Splitwise's pseudo-group for non-group expenses. Sign convention: positive = owed to that member (with current_user_id: owed to you); negative = they (you) owe.

When to Use:

  • To find a group's id before reading, adding an expense to it, or changing its members.

  • For an overview of where you owe or are owed money, group by group.

When NOT to Use:

  • To match a group by a fuzzy name (use splitwise_resolve_group).

  • For one group's members, debts and invite link (use splitwise_get_group).

  • For balances per friend across all groups (use splitwise_get_balances / splitwise_get_friends).

Returns: A markdown table or, with response_format=json, {"count", "offset", "shown", "has_more", "next_offset", "groups": [raw group objects]}.

Pagination: Splitwise returns every group at once; the tool shows 50 per call. When more remain it reports the next offset — call again with offset set to it.

Examples:

  • params = {}

  • params = {"current_user_id": 491923}

  • params = {"offset": 50, "response_format": "json"}

Error Handling: 401 → the API key is missing or was regenerated; network errors are reported as Error: ....

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/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 behavior beyond them: 50-per-call pagination with next-offset, the sign convention for balances, the group id 0 pseudo-group, response-format behavior, and 401/network error handling. This is rich operational context rare in tool descriptions.

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?

Purpose and key caveats are front-loaded, then cleanly sectioned into When to Use / When NOT to Use / Returns / Pagination / Examples / Error Handling. Every section carries unique information; no sentence is filler.

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 read tool with both annotations and an output schema, this description covers everything an agent needs: selection guidance, pagination continuation, sign interpretation, and failure modes. Nothing material is left for the agent to guess.

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?

Despite the low reported schema coverage signal, the description fully explains each parameter's effect: offset ties to the 50-per-call window, current_user_id changes whose balance is shown and flips the sign convention, and response_format governs the return shape. Worked examples show concrete parameter combinations.

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?

The opening sentence states a specific verb and resource ('List every group you belong to') plus the returned columns (members count, balances per currency). It also disambiguates from close siblings like splitwise_get_group and splitwise_get_balances via the When NOT to Use list.

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?

Explicit When to Use and When NOT to Use sections name concrete alternatives (splitwise_resolve_group, splitwise_get_group, splitwise_get_balances) and the conditions that select them. An agent can route correctly without inferring anything.

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