open-splitwise
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_toolsA | Discover the hidden raw Splitwise tools on demand (lazy loading keeps this server's default token footprint tiny). With no query: returns a compact group index. With a query (e.g. 'expenses', 'groups', 'notifications' or a tool name): returns matching tools WITH their full input schemas and registers them into this session so they can be called directly. enable=false only reports. After enabling, clients that support tools/list_changed refresh automatically. |
| setup_authA | Configure or replace the Splitwise API key. Validates the key against Splitwise before saving, so a wrong key is never stored. Ask the user to generate a personal API key at https://secure.splitwise.com/apps and pass it here. |
| get_auth_statusA | Report whether a Splitwise API key is configured, where it came from (stored credential vs environment), and a masked preview. Use this to diagnose auth failures. |
| logoutA | Remove the stored Splitwise API key (log out). Environment-provided keys cannot be removed here and remain active as fallback. |
| resolve_usersA | Resolve human-friendly identifiers (names, partial names, emails, user IDs, 'me') into Splitwise user IDs. Ambiguous names return candidate lists so you can ask the user which one they meant. |
| quick_add_expenseA | Agent-friendly expense creation from messy input. Participants can be names, partial names ('alice'), emails or user IDs; they are resolved automatically. Splits equally among participants plus the payer by default (set include_payer_in_split=false when the payer did not consume); pass owed_shares like {"Alice": "100.00"} for custom amounts that must sum to cost. category_name is fuzzy-matched against Splitwise categories; currency defaults to your default currency. Returns who owes what. |
| money_summaryA | One-call financial overview: per-currency totals of what you are owed vs what you owe across all friends, plus each friend's balance and simplified group debts. Replaces manual aggregation over get_friends/get_groups. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each visible tool has a clearly distinct role: auth setup/status/logout form a lifecycle, resolve_users handles identifier mapping, quick_add_expense creates expenses, and money_summary provides balances. search_tools is explicitly a discovery/meta tool, so there is no meaningful overlap between tools.
Most tools follow a clear verb_noun snake_case pattern such as setup_auth, get_auth_status, resolve_users, quick_add_expense, and search_tools. logout and money_summary deviate slightly as a bare verb and a noun-noun phrase, but the naming remains easily predictable.
Seven tools is a well-scoped count for this server. It covers authentication, user lookup, expense creation, financial summary, and dynamic tool discovery without unnecessary bloat, and the lazy-loading design keeps the default surface compact.
The visible high-level tools cover auth, user resolution, expense creation, and summary, which handles common Splitwise workflows. search_tools explicitly exposes hidden raw tools for expenses, groups, and notifications, mitigating most gaps, though direct visible listing/update/delete expense helpers would make common management tasks more straightforward.