Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_create_friend

Add one person as a Splitwise friend by email to share non-group expenses. Requires writes enabled; provide a first name when the email has no account.

Instructions

Add one person as a Splitwise friend by e-mail. 🔒 Needs SPLITWISE_ALLOW_WRITES=1.

Calls POST /create_friend with user_email (+ user_first_name / user_last_name when given). If an account already exists for that e-mail the names are ignored; if not, Splitwise creates an invited user and user_first_name is required. If you don't know whether they have an account, pass user_first_name; it is ignored for existing users. Adding someone without an account probably sends them an invitation e-mail (unverified; the live smoke t10 confirms). 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 one person so you can share non-group expenses with them.

When NOT to Use:

  • To add several people at once (use splitwise_create_friends).

  • To add someone to a group (use splitwise_add_user_to_group).

  • To check whether someone is already a friend (use splitwise_get_friends or splitwise_resolve_friend).

Returns: A confirmation echoing the friend Splitwise returned: First Last (id N), e-mail and registration status.

Examples:

  • Existing user: params = {"user_email": "grace@example.com"}

  • New user: params = {"user_email": "alan@example.com", "user_first_name": "Alan", "user_last_name": "Turing"}

Error Handling: Error: … writes are disabled → set SPLITWISE_ALLOW_WRITES=1. A 400 usually means an invalid e-mail or a missing first name for a new user. On a 5xx/timeout the outcome is UNKNOWN — check splitwise_get_friends before retrying.

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?

Annotations only declare the generic safety profile; the description goes far beyond, disclosing the SPLITWISE_ALLOW_WRITES=1 gate and its exact refusal message, conditional first-name handling for invited users, the likely invitation e-mail side effect, the absence of any undo, and that a 5xx/timeout leaves the outcome UNKNOWN requiring a get_friends check before retry. That is precisely the behavioral context annotations cannot carry.

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: the action and the write gate appear in the first two lines, followed by clean headed sections. A few sentences carry internal-tooling noise ('the live smoke t10 confirms') that dilutes the signal, but nothing is padding in the harmful sense.

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 mutating, non-idempotent, open-world tool this covers the full call path: config prerequisite, conditional parameter semantics, side effects, return shape, error taxonomy, and retry safety. An output schema exists, yet the 'Returns' section still adds useful confirmation format detail.

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?

Schema coverage is reported at 0% (only the nested object carries field descriptions), so the description must compensate — and it does, explaining that names are ignored for existing accounts, that user_first_name becomes required when no account exists, and providing concrete param examples for both cases. Slightly redundant with the schema's own field descriptions, so not a full 5.

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 and resource ('Add one person as a Splitwise friend by e-mail') and immediately names the underlying operation (`POST /create_friend`). It is unambiguously distinguishable from siblings like splitwise_create_friends and splitwise_add_user_to_group.

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 route the agent to four named alternatives (splitwise_create_friends, splitwise_add_user_to_group, splitwise_get_friends, splitwise_resolve_friend), each with the condition that selects it. This is exemplary routing guidance.

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