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 Server Show me my recent expenses"
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 standalone Model Context Protocol (MCP) server that provides complete access to the Splitwise API. Use it with Claude Desktop, VS Code Copilot, ChatGPT, or any MCP-compatible client to manage your Splitwise expenses through natural language.
26 MCP Tools organized in 7 categories:
š¤ User Management (3) - Profile and settings
š„ Group Management (7) - Create/manage expense groups
š¤ Friend Management (5) - Add/manage friends
š° Expense Management (6) - Create/track expenses with custom splits
š¬ Comments (3) - Comment on expenses
š Notifications (1) - View account activity
š ļø Utilities (2) - Currencies and categories
Related MCP server: gr-splitwise-mcp
ā Claude Desktop (Anthropic's desktop app) - Uses stdio or WebSocket modes
ā VS Code with GitHub Copilot (via splitwise-mcp-vscode extension)
ā ChatGPT (with custom MCP integration)
ā Any MCP-compatible client (stdio or WebSocket+HTTP modes)
npm install
npm run buildVisit secure.splitwise.com/apps and register your app:
Name: My Splitwise MCP
Homepage URL: http://localhost
Callback URL: http://localhost:8080/callback
Save your Consumer Key and Consumer Secret.
Run the token helper:
npm run get-tokenOr manually:
Visit: https://secure.splitwise.com/oauth/authorize?client_id=YOUR_CONSUMER_KEY&response_type=code&redirect_uri=http://localhost:8080/callback
Authorize the app and copy the code from the redirect URL
Exchange for token:
curl -X POST "https://secure.splitwise.com/oauth/token" \
-d "grant_type=authorization_code" \
-d "code=YOUR_AUTH_CODE" \
-d "client_id=YOUR_CONSUMER_KEY" \
-d "client_secret=YOUR_CONSUMER_SECRET" \
-d "redirect_uri=http://localhost:8080/callback"Create .env:
SPLITWISE_ACCESS_TOKEN=your_access_token_hereEdit your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
Mac/Linux: ~/Library/Application Support/Claude/claude_desktop_config.json
WebSocket mode (requires the adapter or direct connection):
{
"mcpServers": {
"splitwise": {
"command": "splitwise-mcp-server",
"args": [],
"env": {
"SPLITWISE_ACCESS_TOKEN": "your_access_token_here",
"PORT": "3002"
}
}
}
}Stdio mode (original, uses stdio transport):
{
"mcpServers": {
"splitwise": {
"command": "splitwise-mcp-server",
"args": ["--stdio"],
"env": {
"SPLITWISE_ACCESS_TOKEN": "your_access_token_here"
}
}
}
}Restart Claude Desktop and test:
"Show me my Splitwise friends"
"List my recent expenses"
"Create a $50 dinner expense split equally"Install the Splitwise MCP VS Code Extension:
# Install the VS Code extension
code --install-extension splitwise-mcp-1.0.0.vsixConfigure your access token in VS Code settings, then use Copilot Chat:
"Show my Splitwise balance"
"Add a $30 grocery expense to my Roommates group"See the VS Code extension README for detailed setup.
The server uses stdio transport and follows the MCP specification. Connect any MCP client:
// Example: Using MCP SDK Client
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';
const transport = new StdioClientTransport({
command: 'splitwise-mcp-server',
env: { SPLITWISE_ACCESS_TOKEN: 'your_token' }
});
const client = new Client({ name: 'my-client', version: '1.0.0' }, { capabilities: {} });
await client.connect(transport);
const tools = await client.listTools();splitwise_get_current_user - Get your profile info
splitwise_get_user - Get another user's info
splitwise_update_user - Update profile settings
splitwise_get_groups - List all groups
splitwise_get_group - Get group details
splitwise_create_group - Create new group
splitwise_delete_group - Delete group
splitwise_restore_group - Restore deleted group
splitwise_add_user_to_group - Add member to group
splitwise_remove_user_from_group - Remove member from group
splitwise_get_friends - List all friends with balances
splitwise_get_friend - Get friend details
splitwise_add_friend - Add single friend
splitwise_add_friends - Add multiple friends
splitwise_remove_friend - Remove friend
splitwise_get_expenses - List/filter expenses
splitwise_get_expense - Get expense details
splitwise_create_expense - Create expense (equal or custom split)
splitwise_update_expense - Update expense
splitwise_delete_expense - Delete expense
splitwise_restore_expense - Restore deleted expense
splitwise_get_comments - Get expense comments
splitwise_add_comment - Add comment to expense
splitwise_delete_comment - Delete comment
splitwise_get_notifications - Get recent activity
splitwise_get_currencies - Get supported currencies
splitwise_get_categories - Get expense categories
View balances:
"What do I owe each of my friends?"
"Show me my Splitwise balance"Create expenses:
"Add a $60 grocery expense split equally in my Roommates group"
"I paid $100 for dinner - I owe $40, John owes $60"
"Create a $1200 monthly rent expense split equally"Manage groups:
"Create a group called 'Vegas Trip' and add alice@email.com"
"Who's in my Apartment group?"
"Show me all expenses in the Weekend Getaway group"Filter expenses:
"Show me restaurant expenses from last month"
"List all expenses over $100"
"What did I spend the most on this year?"Authentication failed:
Verify token in .env matches the one in claude_desktop_config.json
No extra spaces or quotes around the token
Token hasn't expired - regenerate with npm run get-token
Server not found:
Use absolute path in config
Windows: Use \\ (double backslashes)
Run npm run build after code changes
Path should point to dist/index.js not src/index.ts
Tools not appearing in Claude:
Verify JSON syntax in claude_desktop_config.json
Completely close and restart Claude Desktop (check system tray)
Check Claude Desktop logs: Help ā Show Logs
Authorization code expired:
Codes expire in 10 minutes
Get a new code and exchange immediately
Use the token helper script to automate: npm run get-token
For detailed setup instructions, see SETUP.md
The Splitwise MCP server supports multiple deployment modes:
npm run dev:ws
# or
PORT=4001 npm startStarts on port 4001 (configurable via PORT env var)
Uses WebSocket + HTTP JSON-RPC protocol
Recommended for production deployments
Can be used with HTTP adapter for remote access
npm run dev:stdio
# or
npm start -- --stdioUses standard input/output (classic MCP protocol)
Good for direct client integration
Default mode when --stdio flag is passed
Recommended for Claude Desktop
npm run dev:adapter
# or in another terminal while WebSocket server is running:
WS_BACKEND_URL=ws://localhost:4001 npm run adapterRuns on port 4000 (configurable via PORT env var)
Proxies HTTP/JSON-RPC requests to the WebSocket backend
Provides HTTP endpoints for testing:
GET /health - Health check
GET /status - Backend connection status
GET /listTools - List available tools
POST /rpc - JSON-RPC request endpoint
POST / - Alternative JSON-RPC endpoint
WS / - WebSocket upgrade endpoint
# Install dependencies
npm install
# Build TypeScript
npm run build
# Watch mode (auto-rebuild)
npm run watch
# WebSocket mode (default)
npm run dev:ws
# Stdio mode
npm run dev:stdio
# HTTP Adapter mode (in separate terminal with backend running)
npm run dev:adapter
# Get OAuth token
npm run get-token# Terminal 1: Start WebSocket backend
PORT=4001 npm run build
PORT=4001 npm run dev:ws
# Terminal 2: (Optional) Start HTTP adapter
PORT=4000 npm run dev:adapter
# Terminal 3: Test the server
curl http://localhost:4000/health
curl http://localhost:4000/listToolsConfigure as shown in "Option A: Claude Desktop" above
Run the server: PORT=4001 npm start
Restart Claude Desktop
Configure with --stdio flag as shown above
Run the server: npm start -- --stdio
Restart Claude Desktop
SplitwiseMCPServer/
āāā src/
ā āāā index.ts # Main MCP server (WebSocket + Stdio modes)
ā āāā http-adapter.ts # HTTP adapter for WebSocket backend
ā āāā splitwise-client.ts # Splitwise API wrapper
ā āāā tools.ts # Tool definitions (26 tools)
ā āāā get-token.ts # OAuth helper script
āāā dist/ # Compiled output
āāā .env # Your credentials (not in git)
āāā package.json
āāā tsconfig.jsonAll tools follow the Splitwise API v3.0 specification: dev.splitwise.com
Base URL: https://secure.splitwise.com/api/v3.0
Authentication: OAuth 2.0 Bearer Token
Never commit .env to version control
Keep your access token private
Use environment variables for credentials
Set proper file permissions: chmod 600 .env (Unix/Mac)
Node.js: 18+
NPM: Latest
Splitwise Account: Free or premium
MIT
Splitwise MCP VS Code Extension - Optional VS Code integration
Splitwise API Documentation - Official API reference
Model Context Protocol - MCP specification
Contributions welcome! Please:
Fork the repository
Create a feature branch
Make your changes
Submit a pull request
Issues: GitHub Issues
Splitwise API: dev.splitwise.com
MCP Docs: modelcontextprotocol.io
MIT License - see LICENSE file for details
Built with: TypeScript 5.3, MCP SDK 1.20.1, Axios 1.6.0
Create a new expense. Can split equally among group members or specify custom shares for each user. For custom shares, provide users array with paid_share and owed_share for each user.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | Yes | Total cost as a decimal string (e.g., "25.00") | |
| date | No | Date of expense (ISO 8601 format). Defaults to now. | |
| users | No | Array of user share objects (required if not splitting equally). Each must have paid_share, owed_share, and either user_id or email/first_name/last_name | |
| details | No | Additional notes about the expense | |
| group_id | No | Group ID (0 for expenses outside a group) | |
| category_id | No | Category ID from get_categories | |
| description | Yes | Short description of the expense | |
| currency_code | No | Currency code (e.g., "USD") | |
| split_equally | No | Whether to split equally among group members | |
| repeat_interval | No | Repeat frequency |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool creates an expense and splits options, but fails to mention side effects, authorization needs, or return behavior. More detail on what happens upon creation is needed.
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?
The description is two concise sentences. The first sentence states the core purpose, and the second expands on the key parameter behavior. No wasted words.
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?
Given 10 parameters (2 required) and no output schema, the description adequately covers the splitting logic but omits explanation of many optional parameters (e.g., repeat_interval, category_id) and the return value. It is minimally complete.
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%, but the description adds value by clarifying the purpose of the users array for custom shares and implying that split_equally negates the need for users. This goes beyond the schema descriptions.
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?
The description clearly states 'Create a new expense' with a specific verb and resource. It also distinguishes between equal splits and custom shares, differentiating this create tool from related siblings like update, delete, and get.
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?
The description explains when to use equal splitting vs. custom shares, providing clear context. However, it does not explicitly mention prerequisites (e.g., needing a group ID) or alternative tools for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an expense permanently.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The expense ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states 'permanently' but does not clarify if deletion is reversible via restore_expense, nor does it mention permissions or side effects. This lack of detail reduces transparency.
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: two words with no filler. Every word adds value.
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 destructive tool with no annotations or output schema, the description is insufficient. It lacks information on reversibility, authorization requirements, and potential side effects, leaving the agent with incomplete 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?
Schema description coverage is 100%, and the description adds no extra meaning beyond what the schema already says about the 'id' parameter. Baseline score of 3 is appropriate.
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?
The description clearly states the action (delete) and resource (an expense), and the word 'permanently' distinguishes it from reversible operations like restore_expense.
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 on when to use this tool versus alternatives (e.g., update_expense or restore_expense). No prerequisites or conditions provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all expense categories supported by Splitwise. Use subcategory IDs when creating expenses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation with no side effects, but lacks details such as pagination, sorting, or any potential restrictions. Without annotations, more behavioral context would be beneficial.
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 concise sentences with no wasted words. The description is front-loaded and efficient.
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?
Given no parameters, no output schema, and a simple purpose, the description is nearly complete. It could mention return format or typical usage more explicitly, but overall adequate.
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?
There are no parameters, so the schema provides full coverage. The description adds value by mentioning subcategory IDs, which hints at the output structure. Baseline 4 is appropriate.
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?
The description clearly states it gets a list of expense categories from Splitwise. It distinguishes from sibling tools (groups and expenses) by being the only category-related tool.
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?
It provides a specific usage hint: 'Use subcategory IDs when creating expenses,' which guides the agent on how to use the output. However, it does not explicitly state when not to use this tool or mention alternatives, though none exist in siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific expense, including all users involved and their shares.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The expense ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states output includes 'all users and their shares' but omits typical side effects (none for reads), error handling, permission requirements, or rate limits.
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?
A single, clear sentence with no fluff. Front-loaded with the purpose.
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?
The tool is simple (one param, no output schema). The description gives a reasonable picture of what to expect ('detailed information including all users and their shares'), though it could mention other fields like cost or date.
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 one parameter ('id') described as 'The expense ID'. The description does not add additional meaning 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?
The description clearly states the verb 'Get', the resource 'expense', and specifies the scope ('detailed information including all users and their shares'). It effectively distinguishes from sibling tools like splitwise_get_expenses (list) and splitwise_delete_expense.
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 explicit guidance on when to use this tool versus alternatives. The context is implied for fetching a single expense, but no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List expenses with optional filters. Can filter by group, friend, date range, or update time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of expenses to return (default: 20) | |
| offset | No | Offset for pagination (default: 0) | |
| group_id | No | Filter by group ID | |
| friend_id | No | Filter by friend user ID | |
| dated_after | No | Filter expenses dated after this date (ISO 8601 format) | |
| dated_before | No | Filter expenses dated before this date (ISO 8601 format) | |
| updated_after | No | Filter expenses updated after this time (ISO 8601 format) | |
| updated_before | No | Filter expenses updated before this time (ISO 8601 format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only mentions list and filter options, but omits key details like pagination behavior, sorting order, data freshness, or read-only nature. Significant gaps remain.
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?
The description is concise with two front-loaded sentences. Every word earns its place, though it could be more informative without significant added length.
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?
Given 8 optional parameters, no required params, no output schema, and no annotations, the description is incomplete. An agent needs more context on pagination defaults, result ordering, and data scope to use the tool effectively.
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%, so the baseline is 3. The description summarizes filter types (group, friend, date range) but adds no new meaning beyond the schema's parameter descriptions, which already include ISO 8601 format hints.
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?
The description clearly states it lists expenses with optional filters, which distinguishes it from sibling tools like get_expense (singular) or create_expense. The verb 'list' and plural 'expenses' imply multiple results, but it could explicitly contrast with get_expense.
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 is provided on when to use this tool versus alternatives like get_expense for a single expense, or when not to use it. The description lacks context for selecting this tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific group, including members, balances, and settings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The group ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool returns 'detailed information' but does not disclose error handling, idempotency, or rate limits. For a simple read operation, this is adequate but minimal.
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 front-loaded verb and resource. No wasted words; every part is informative.
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?
Given no output schema, the description provides useful output expectations (members, balances, settings). For a single-parameter get tool, this is nearly complete. Could list more fields but not necessary for basic understanding.
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 a clear description for the 'id' parameter. The description adds value by listing included fields (members, balances, settings), but this is about output rather than parameters. Baseline 3 is appropriate.
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?
The description clearly states 'Get detailed information about a specific group' with verb and resource, and includes specifics (members, balances, settings). It distinguishes from siblings like splitwise_get_groups (list groups) and splitwise_get_expenses (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?
The description implies usage when needing group details, but does not explicitly state when to use or avoid this tool versus alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all groups for the current user. Groups represent collections of users who share expenses together (e.g., household, trip, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains the conceptual meaning of groups but does not explicitly state that the operation is read-only, non-destructive, or has no side effects. The name 'get_groups' implies safety, but the description could be more explicit.
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 short sentences that are front-loaded with the main action. The first sentence states what it does, the second provides clarifying context. No wasted words, every sentence adds value.
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?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough. It explains the purpose and what a group represents. However, it does not mention potential limitations like pagination or data freshness, which might be relevant for a list operation.
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?
There are zero parameters, and the schema coverage is 100%. The description does not need to add parameter details. Baseline score of 4 is appropriate as the description explains the tool's purpose without needing to elaborate on 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?
Description clearly states the action 'List' and the resource 'all groups for the current user'. It also distinguishes from the sibling tool 'splitwise_get_group' by implying it returns a list rather than a single group. The explanation of what groups are adds context, making the purpose specific and unambiguous.
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?
The description implies the tool is for listing all groups, and siblings like 'splitwise_get_group' are for specific groups, but it does not explicitly state when to use this tool over alternatives. No exclusion criteria or fallback guidance is provided, though the simplicity reduces the need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a deleted expense.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The expense ID to restore |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the restore is reversible, what happens if the expense is not deleted, or if any permissions are required.
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?
The description is a single concise sentence that front-loads the main action. While efficient, it could be slightly expanded to include return behavior without losing conciseness.
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?
Given the simple one-parameter tool and no output schema, the description is minimally adequate but lacks context about success/failure responses or idempotency.
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?
The input schema has 100% coverage with a clear parameter description. The tool's description adds no additional meaning beyond the schema, meeting the baseline score of 3.
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?
The description clearly states the action (restore) and resource (deleted expense), distinguishing it from sibling tools like delete or get 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?
No explicit guidance on when to use this tool versus alternatives, but the name and context imply it is for undeleting expenses; lacking specific conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing expense. Only include fields that are changing. If users array is provided, all shares will be overwritten.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The expense ID to update | |
| cost | No | Total cost as a decimal string | |
| date | No | Date of expense (ISO 8601 format) | |
| users | No | Array of user share objects to update. If provided, replaces all existing shares. | |
| details | No | Additional notes about the expense | |
| group_id | No | Group ID | |
| category_id | No | Category ID | |
| description | No | Short description of the expense | |
| currency_code | No | Currency code | |
| repeat_interval | No | Repeat frequency |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a key behavior: providing a users array overwrites all existing shares. However, it does not mention other important aspects such as idempotency, authorization requirements, or what the tool returns. Given the expected update behavior, the description is adequate but not comprehensive.
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?
The description consists of two concise sentences with no redundancy. The first sentence states the primary purpose, and the second provides critical usage guidance. Every word earns its place, making it highly efficient for an AI agent to parse.
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?
Given the moderate complexity (10 parameters, all documented in schema) and no output schema, the description covers the most important behavioral aspects. It lacks explanation about return values, but since no output schema exists, this is a minor gap. The guidance on partial updates and users array overwrite is valuable. Overall, the description is complete enough for an agent to use correctly.
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%, so baseline is 3. The description adds practical value beyond the schema by explaining usage patterns: 'Only include fields that are changing' and the specific behavior of the users array. This helps the agent decide which parameters to include and understand side effects.
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?
The description clearly states the tool's purpose: 'Update an existing expense.' It distinguishes from sibling tools like splitwise_create_expense and splitwise_delete_expense by focusing on modification. Further nuance is added with guidance on updating partial fields and the behavior of the users array.
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?
The description provides clear context: use this tool to update an existing expense. It advises to 'only include fields that are changing' and warns about overwriting shares when providing users array. While it doesn't explicitly list when not to use or alternatives, the sibling tools offer obvious alternatives (create, delete) and the guidance is sufficient for an update tool.
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.0splitwise_create_expensesplitwise_delete_expensesplitwise_get_categoriessplitwise_get_expensesplitwise_get_expensessplitwise_get_groupsplitwise_get_groupssplitwise_restore_expensesplitwise_update_expenseEach tool targets a distinct resource and action: groups vs expenses vs categories, and within expenses, the CRUD operations are clearly separated. There is no ambiguity between tools.
All tools follow a consistent 'splitwise_verb_noun' pattern using snake_case, with verbs like get, create, update, delete, restore, and nouns like groups, group, expenses, expense, categories. No mixing of conventions.
9 tools is well-scoped for an expense sharing server. It covers group retrieval, expense management (CRUD + restore), and categories without being too sparse or overwhelming.
The tool set provides robust expense management (create, read, update, delete, restore) and group info retrieval. However, missing group CRUD (create/update/delete) and friend management, which are minor gaps for the core expense tracking domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Nifty's MCP server ā exposes tasks, projects, messages, and files as tools for AI agents.
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.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/svarun115/splitwise-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
