Loading ToolBench
A comprehensive Model Context Protocol server for managing Splitwise accounts
The server defines 27 tools with mostly present but inconsistent schemas and descriptions. All tools have names following verb_noun convention and are properly prefixed with 'splitwise_'. Descriptions are generally adequate (100-250 chars on average), exceeding the 10-char minimum but falling short of the 50-200 char LLM-optimized range for most tools. Input schemas are fully defined with proper JSON Schema structure, types, and required fields. However, parameter descriptions are minimal or missing rationale for interdependencies. Output schemas are not documented, a critical gap for LLMs planning downstream calls. Error handling is present but lacks actionable recovery guidance. Security concerns exist around password exposure (splitwise_update_user exposes 'password' as a parameter). Tool composition is logical but some tools lack clarity on mutual exclusivity (e.g., user_id vs email in add_user_to_group). Overall, the toolkit is functional but leaves room for LLM optimization and downstream integration.
Add a new friend. If the user exists, first_name and last_name are ignored. If creating a new user, first_name is required.
Add multiple friends at once. Provide users array with email/first_name/last_name for each.
Add a user to an existing group. Provide either user_id or email/first_name/last_name.
Add a comment to an expense.
Create a new expense. Can split equally or custom splits between users. User fields should be in the format users__0__user_id, users__1__paid_by, etc.
Create a new group. Can add users by providing their email/name or user_id. User fields should be in the format users__0__email, users__0__first_name, etc.
Password exposed as tool parameter in splitwise_update_user. Credentials must never appear as parameters; use server-side secret injection instead.
Output schemas not documented. LLMs cannot plan downstream tool calls without knowing what fields are returned (e.g., what does create_group return? Just group_id? Include group_name, members list?). This forces discovery calls and risks broken chains.
Parameter interdependencies not documented. Tools like add_user_to_group accept user_id OR (email + optional first_name/last_name), but descriptions do not explicitly state mutual exclusivity. LLMs may pass both, causing ambiguous or failing calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 79 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | 2024-11-05+ | v1 |
Delete a comment from an expense.
Delete an expense. This removes the expense and all associated payments.
Delete a group. This destroys all associated records including expenses.
Get a list of all expense categories available in Splitwise.
Get all comments on a specific expense.
Get a list of all supported currencies in Splitwise.
Get information about the currently authenticated Splitwise user, including their ID, name, email, notification settings, and default currency.
Get detailed information about a specific expense, including cost breakdown and payment history.
List expenses with optional filters. Can filter by group, friend, date range, or update time.
Get detailed information about a specific friend, including shared groups and balances.
List all friends of the current user, including balance information.
Get detailed information about a specific group, including members, balances, and settings.
List all groups for the current user. Groups represent collections of users who share expenses together (e.g., household, trip, etc.).
Get notifications about activities in your Splitwise account.
Get information about another Splitwise user by their user ID.
Remove a friend connection. This breaks off the friendship between the current user and the specified user.
Remove a user from a group. Note: This only succeeds if the user has a zero balance in the group.
Restore a deleted expense.
Restore a deleted group.
Update an existing expense. Can modify cost, description, date, splits, and other details.
Update information for a Splitwise user. Can update first name, last name, email, password, locale, and default currency.
splitwise_get_expenses includes a friend_id parameter with a warning that passing 0 causes a permission error. This is a misuse trap, the description should instead say 'Optional. Omit entirely to not filter by friend' and handle null/undefined internally, not warn about invalid values.
splitwise_create_expense and splitwise_update_expense lack clear guidance on split configuration. Parameters mention 'split_equally' but do not explain how to specify custom splits or what happens if splits are omitted. The note 'User fields should be in the format users__0__user_id' is unclear, does the schema accept flattened keys, or is this a documentation artifact?
No error handling documentation. Tools return generic success/failure responses without actionable recovery guidance (e.g., 'User not found. Try search_users() with a partial name'). Agents cannot determine if errors are retryable, user-fixable, or fatal.
No confirmation/dry-run pattern for destructive operations (delete_group, delete_expense). Agents can irreversibly destroy data without a confirmation step. Implement a dry-run mode or confirmation_required response pattern.
Date/time format specifications are vague. Parameters like 'dated_after' and 'updated_after' say 'ISO 8601 format' but do not clarify timezone handling, precision (seconds vs milliseconds), or what happens if the format is wrong. LLMs frequently miscalculate timestamp conversions, explicit guidance is essential.
No pagination documentation for list operations (get_groups, get_friends, get_expenses, get_notifications). If these return large result sets, LLMs need limit/offset or cursor guidance to avoid context window exhaustion. Current descriptions do not mention pagination or result limits.