Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_create_friends

Add several people as Splitwise friends in a single batch before sharing group expenses. Supply emails and optional names to create accounts when needed.

Instructions

Add several people as Splitwise friends in one call. 🔒 Needs SPLITWISE_ALLOW_WRITES=1.

Calls POST /create_friends with the list flattened to users__{i}__email / users__{i}__first_name / users__{i}__last_name (index from 0). Names matter only for people without a Splitwise account yet. Splitwise answers HTTP 200 even when it rejects entries, so success is read from the body's errors. Refused with Error: … writes are disabled unless SPLITWISE_ALLOW_WRITES=1. There is no undo tool; remove a friend with splitwise_delete_friend.

When to Use:

  • To befriend a list of people (e.g. trip companions) before sharing expenses.

When NOT to Use:

  • For a single person (use splitwise_create_friend).

  • To put people in a group (use splitwise_create_group / splitwise_add_user_to_group).

Returns: A confirmation listing every user Splitwise returned (First Last (id N), e-mail, registration status) and the body's errors (none on success). On a rejected batch the Error: is followed by the users Splitwise still listed in users[] (probably the ones it added) and a read-back hint.

Examples:

Error Handling: Duplicate e-mails in the list are rejected locally before any call. If Splitwise reports any error the call is returned as an Error: — the people its response still listed are named under it (probably added), so read back with splitwise_get_friends before retrying. On a 5xx/timeout the outcome is UNKNOWN.

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 past the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it discloses the SPLITWISE_ALLOW_WRITES=1 write gate and the exact refusal message, warns that Splitwise returns HTTP 200 even on rejection so success must be read from body `errors`, notes there is no undo tool, states duplicate e-mails are rejected locally before any call, and flags that a 5xx/timeout leaves the outcome UNKNOWN. None of this is derivable from structured fields.

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 purpose and the write-gate warning, then cleanly partitioned into When to Use / When NOT to Use / Returns / Examples / Error Handling. It is longer than strictly necessary — the Returns section duplicates information the output schema already carries — but each block is scannable and earns most of its space.

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 non-idempotent, open-world write tool with an output schema present, the description covers everything an agent needs: auth prerequisite, the deceptive 200-on-error behavior, partial-success read-back procedure via splitwise_get_friends, unknown-outcome semantics on transport failure, and no-undo recovery via splitwise_delete_friend.

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?

Reported schema description coverage is 0%, so the description must carry parameter meaning, and it does: it explains the flattening to users__{i}__email/first_name/last_name with 0-based indexing, clarifies that names matter only for people without an account, and supplies a concrete two-element params example. Minor gap: it does not restate the 1-50 item bound or the e-mail format constraint that live in the schema.

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+scope: 'Add several people as Splitwise friends in one call,' where 'several' and 'in one call' signal the bulk nature. It explicitly contrasts with the single-person sibling ('For a single person (use splitwise_create_friend)'), so an agent can route between them without opening either 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 naming concrete alternatives (splitwise_create_friend, splitwise_create_group, splitwise_add_user_to_group) with the condition that selects each. This is the textbook routing guidance an agent needs.

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