Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@splitwise-mcp Add a $45 dinner split equally with Sarah"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Splitwise — manage shared expenses directly from Claude, Cursor, or any MCP-compatible AI assistant.
No well-maintained Splitwise MCP existed. This one does.
Tool | Description |
| List expenses — filter by group, friend, date range |
| Get a single expense by ID |
| Create a new expense with per-user splits |
| Delete an expense by ID |
| List all friends with IDs and balances |
| List all groups with members and debts |
| Pre-computed net balance summary (who owes you, who you owe) |
| Get your Splitwise user ID |
Related MCP server: Splitwise MCP Server
Go to splitwise.com/apps
Register an app (or use existing) → copy the API Key
Set env var: SPLITWISE_API_KEY=your_api_key
Go to splitwise.com/apps → register an app
Copy Consumer Key and Consumer Secret
Complete the OAuth 1.0 flow to get an access token and secret
Set env vars:
SPLITWISE_CONSUMER_KEY=your_consumer_key
SPLITWISE_CONSUMER_SECRET=your_consumer_secret
SPLITWISE_ACCESS_TOKEN=your_access_token
SPLITWISE_ACCESS_TOKEN_SECRET=your_access_token_secretAdd to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"splitwise": {
"command": "npx",
"args": ["splitwise-mcp"],
"env": {
"SPLITWISE_API_KEY": "your-api-key-here"
}
}
}
}Restart Claude Desktop — you'll see the Splitwise tools available.
"What do I owe on Splitwise?"
"Show me all expenses from last month"
"Add a $60 dinner split equally between me and Alice"
"Which of my friends owes me the most?"
"Show me all expenses in my Roommates group"
git clone https://github.com/SaharshPatel24/splitwise-mcp
cd splitwise-mcp
npm install
npm run build
# Run with your API key
SPLITWISE_API_KEY=your_key node dist/index.jsMIT
Create a new Splitwise expense with explicit per-user splits. Always confirm split details with the user before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Expense description e.g. "Dinner at Nobu" | |
| cost | Yes | Total cost as decimal string e.g. "42.50" | |
| date | Yes | ISO date e.g. 2025-03-15 | |
| currency_code | No | Currency code e.g. USD, EUR (default USD) | |
| group_id | No | Group ID if this is a group expense | |
| users | Yes | All involved users with their paid and owed shares |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Contains 'confirm before calling' hinting at irreversibility/sensitivity, but omits specific side effects (balance mutations, group notifications, permanence) and error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First states purpose, second states critical safety prerequisite. Appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mutation tool with rich schema (100% coverage) but no annotations or output schema. Safety guideline included, but lacks disclosure of return values, failure modes, and financial side effects expected for expense creation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds conceptual context ('explicit per-user splits') aligning with the complex users array structure, but does not add syntax, format constraints, or examples beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Create') and resource ('Splitwise expense') with specific differentiator ('explicit per-user splits'). Lacks explicit differentiation from siblings, though no siblings create expenses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite action ('Always confirm split details with the user before calling'), indicating sensitive/high-stakes usage. Does not specify when to use alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Splitwise expense by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Splitwise expense ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It states 'Delete' but fails to clarify whether deletion is permanent, whether it triggers balance recalculations between users, or if there are permission constraints. For a financial/destructive operation, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 7 words. No wasted text, but arguably under-specified for a destructive operation. The front-loading is appropriate with the action verb leading, though the brevity sacrifices necessary behavioral warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter deletion tool with no output schema and no annotations, the description meets the bare minimum mechanical definition but fails to provide safety-critical context. Missing: permanence warnings, side effects on balances, and success/failure indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'id' parameter fully documented as 'Splitwise expense ID to delete'. The description mentions 'by ID' but adds no semantic value beyond the schema (e.g., where to find the ID, format specifics). Baseline 3 is appropriate given the schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Delete') and resource ('Splitwise expense') with specific scope ('by ID'). However, it lacks explicit differentiation from sibling tools like get_expense or create_expense, which would help the agent confirm this is the correct operation for removal versus retrieval or creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., whether the expense must be retrieved first to verify ownership). The description states the mechanics but not the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently authenticated Splitwise user — useful to find your own user ID when creating expense splits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Mentions authentication requirement ('currently authenticated') and hints at return value ('find your own user ID'), but does not specify read-only safety, rate limits, or full response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with em-dash structure. Front-loaded with action, followed by utility. No redundancy or wasted words given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a zero-parameter utility. Without output schema, the description compensates by indicating the return contains user ID information. Could be improved by explicitly stating 'returns user profile' or 'safe read operation', but covers essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present (baseline 4). Description correctly implies no inputs are needed, though with 100% schema coverage (empty object), no additional parameter documentation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with clear resource 'currently authenticated Splitwise user'. The em-dash clause implicitly distinguishes from sibling tools by explaining the primary use case (finding user ID for create_expense), establishing its unique role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States explicit utility context 'when creating expense splits', linking the tool to the sibling create_expense workflow. Lacks explicit 'when not to use' guidance or alternative comparisons, but provides clear positive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Splitwise expense by ID with full split details.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Splitwise expense ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds 'with full split details' indicating response richness, but omits other behavioral traits like error conditions, auth requirements, or idempotency guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 9-word sentence with zero waste. Front-loaded action ('Get'), immediate scope ('single'), and trailing detail qualifier ('full split details'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for low complexity (1 param, 100% schema coverage). Mentions 'full split details' to compensate for missing output schema, though could further clarify return structure or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% ('Splitwise expense ID' already documented). Description reinforces with 'by ID' but adds no additional semantic depth regarding format, constraints, or examples beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' with clear resource 'Splitwise expense'. 'Single' distinguishes from sibling tool 'get_expenses' (plural), and 'by ID' clarifies the lookup method against other potential filter mechanisms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies distinction from 'get_expenses' via 'single' and 'by ID', but lacks explicit when-to-use guidance (e.g., 'use when you have a specific expense ID, use get_expenses for listing').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Splitwise expenses. Filter by group, friend, date range, or limit. Returns cost, description, date, who paid, and splits.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | No | Filter by group ID | |
| friend_id | No | Filter by friend ID | |
| dated_after | No | ISO date e.g. 2025-01-01 | |
| dated_before | No | ISO date e.g. 2025-01-31 | |
| limit | No | Max results (default 20) | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return value structure ('cost, description, date, who paid, and splits') which substitutes for missing output schema. Omits auth requirements and rate limits but covers essential read-operation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose declaration, filtering capabilities, and return values. Perfectly front-loaded and appropriately sized for complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a list operation with 100% schema coverage. Return values documented in lieu of output schema. Minor gap: does not explicitly describe pagination behavior (offset param in schema but not mentioned in description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds value by semantically grouping parameters as filters ('Filter by group, friend, date range, or limit'), clarifying their purpose beyond raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('List') + resource ('Splitwise expenses') + scope. Plural 'expenses' and filtering description distinguish from sibling get_expense (singular) and clearly contrast with create/delete mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage through filtering examples but does not explicitly differentiate when to use this vs get_expense (single fetch) or contrast with mutating siblings. No 'when-not' guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a pre-computed net balance summary — who owes you, who you owe, and your overall net position across all friends. Much faster than manually summing raw balances.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided so description carries full burden. Adds critical behavioral trait 'pre-computed' (caching) and performance characteristics. Omits data freshness/staleness details, read-only safety confirmation, or permission requirements—gaps expected for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy: first defines output content (three components), second establishes performance advantage. Front-loaded with specific resource identification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description compensates by detailing return content structure ('who owes you, who you owe, overall net position'). Omits specific data types or nesting, but appropriate for simple aggregation tool with zero inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, setting baseline per rubric. Description confirms absence of filtering by specifying 'across all friends', aligning empty schema with universal scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' + resource 'net balance summary' with concrete scope 'across all friends'. Clearly distinguishes from sibling get_expenses (raw transactions vs pre-computed aggregates) and get_friends (basic metadata vs financial balances) via 'pre-computed' and 'net position' language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear performance context ('Much faster than manually summing raw balances') implying when to use this cached view versus calculating from get_expenses. Lacks explicit 'when not to use' or named sibling alternative, positioning it between implied usage and explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Splitwise friends with their IDs, names, emails, and current balances. Use this to look up user IDs before creating expenses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It compensates by disclosing the specific fields returned (IDs, names, emails, balances), which substitutes for the missing output_schema. Could improve by explicitly noting this is a safe read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total with zero waste. First sentence defines operation and payload structure; second provides usage context. Information density is high and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for low complexity: describes the return payload to compensate for missing output_schema, explains the workflow use case, and covers essential behavioral traits. Minor gap: does not mention pagination behavior for users with many friends.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, which per guidelines establishes a baseline of 4. Description correctly omits parameter discussion as none exist; schema coverage is trivially 100% for empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'List' with resource 'Splitwise friends' and detailed scope (IDs, names, emails, balances). Second sentence distinguishes from sibling tools by linking to the create_expense workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('before creating expenses') and for what purpose ('look up user IDs'), providing clear workflow guidance and implicitly distinguishing from other retrieval tools like get_friend_balances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Splitwise groups with member details, group IDs, and current debts within each group.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It compensates partially by describing return data contents (member details, debts) since no output schema exists, but lacks explicit read-only/safety confirmation, pagination details, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single well-structured sentence, front-loaded with the action verb. No redundant words; every clause adds specific information about either the resource or the returned data fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple zero-parameter list operation. The description compensates for missing output schema by enumerating what data is returned (IDs, members, debts), though it could note the read-only nature given lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present (schema is empty object), which per guidelines sets baseline to 4. Description correctly avoids mentioning non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'List' and resource 'Splitwise groups' with specific scope (member details, group IDs, debts). However, it does not explicitly distinguish from sibling tools like get_friends or get_expenses, though the domain separation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus get_friends or get_expenses, nor any prerequisites or workflow context. Only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0create_expensedelete_expenseget_current_userget_expenseget_expensesget_friend_balancesget_friendsget_groupsEvery tool has a distinct purpose with clear boundaries: create/delete/get expense operations, user/friend/group retrieval, and balance summaries. No overlap exists between tools like get_expenses (list) and get_expense (single), or between get_friend_balances (summary) and get_friends (detailed list).
All tools follow a consistent verb_noun pattern (e.g., create_expense, get_expenses, get_friend_balances) with no deviations in style. The naming is predictable and readable throughout the set.
With 8 tools, the count is well-scoped for managing Splitwise expenses, users, friends, groups, and balances. Each tool serves a clear and necessary function without redundancy, fitting a typical utility server range.
The toolset covers core Splitwise operations: CRUD for expenses, retrieval of user/friend/group data, and balance summaries. A minor gap exists in updating expenses (e.g., update_expense), but agents can work around this by deleting and recreating, and other workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SaharshPatel24/splitwise-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
