splitwise-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every 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).
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![splitwise-mcp MCP server](https://glama.ai/mcp/servers/SaharshPatel24/splitwise-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SaharshPatel24/splitwise-mcp)

Score Badge

Copy to your README.md:

[![splitwise-mcp MCP server](https://glama.ai/mcp/servers/SaharshPatel24/splitwise-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SaharshPatel24/splitwise-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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