Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_create_group

Start a shared-expenses group for a trip, home, or couple; optionally invite members by existing user ID or by email in one call.

Instructions

Create a group, optionally with members (you are added automatically). 🔒 write.

Calls POST /create_group with name, group_type, simplify_by_default and the members flattened to users__{i}__user_id or users__{i}__email / users__{i}__first_name / users__{i}__last_name. Each member is EITHER an existing user_id OR an email + first_name (+ last_name) to invite — checked locally before any call. Refused with Error: … writes are disabled unless SPLITWISE_ALLOW_WRITES=1. Undo: splitwise_delete_group with the returned id.

When to Use:

  • To start a new shared-expenses group (a trip, a flat, a couple).

When NOT to Use:

  • To add someone to an existing group (use splitwise_add_user_to_group).

  • To bring back a deleted group (use splitwise_undelete_group).

  • To find a friend's user id by name first (use splitwise_resolve_friend).

Returns: A confirmation echoing what Splitwise returned: the new group's name, id, type and members, plus how many members were requested vs returned (a silently dropped invite shows up there).

Examples:

  • params = {"name": "Lima trip", "group_type": "trip", "members": [{"user_id": 5823}]}

  • params = {"name": "Flat", "group_type": "home", "simplify_by_default": true, "members": [{"email": "ana@example.com", "first_name": "Ana", "last_name": "Diaz"}]}

Error Handling: A member with both or neither identity is rejected before the call. Splitwise's 400 field errors (e.g. a blank name) are surfaced as Error (400): ....

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 cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), and the description goes well beyond them: the SPLITWISE_ALLOW_WRITES=1 write gate and its exact refusal message, the local pre-call identity validation, the undo path via splitwise_delete_group, and the requested-vs-returned member count that surfaces silently dropped invites.

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-loaded with the core action and structured under clear headings (When to Use, When NOT to Use, Returns, Examples, Error Handling), with two worked examples. It is longer than strictly necessary, but nearly every line adds operational value rather than restating structured data.

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 write tool with real prerequisites, the definition covers gating, validation, undo, error surfacing, and examples. An output schema exists, so the brief 'Returns' note is sufficient and the description need not detail the response shape further.

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 carries the burden and does so thoroughly: it documents the body serialization (users__{i}__user_id / email / first_name / last_name), the either/or identity rule per member, and the group_type values. This meaningfully exceeds what the raw schema exposes.

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 ('Create a group') and immediately notes the auto-inclusion of the caller. The 'When NOT to Use' block names the exact sibling tools for adjacent operations, so the agent can distinguish this from splitwise_add_user_to_group, splitwise_undelete_group, and splitwise_resolve_friend without opening a 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?

Explicit 'When to Use' (new shared-expenses group: trip, flat, couple) and 'When NOT to Use' with a named alternative per exclusion case. This is the full when/when-not/alternatives pattern.

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