splitwise-mcp

by sarathfrancis90

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool maps to a distinct resource-action pair, so there is no real overlap: expense CRUD, group lifecycle, member management, comments, settlements, and account info are cleanly separated. Even pairs like delete_expense/undelete_expense and delete_group/undelete_group are complementary opposites rather than ambiguous alternatives.
Naming Consistency4/5
The naming mostly follows a clear verb_noun pattern: list_expenses, get_group, create_expense, update_expense, delete_comment, manage_group_members. Minor deviations like whoami and settle_up are readable and conventional, so the set remains predictable despite not being perfectly uniform.
Tool Count4/5
At 17 tools, this is slightly above the typical 3-15 range, but each tool covers a genuine operation needed for Splitwise workflows. The count feels justified rather than bloated, since expense, group, comment, member, settlement, and account concerns all have dedicated actions.
Completeness4/5
The expense and group lifecycles are well covered with create, read, list, update, delete, and undelete operations, plus member management, comments, settlements, and friend/account views. Minor gaps exist, such as no update_group and no standalone comment listing, but get_expense exposes the comment thread and the missing operations are not critical dead ends.
Average 4.2/5 across 16 of 17 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive intent (destructiveHint=false). The description adds no behavioral detail beyond what annotations state, such as side effects or error cases. It does not contradict annotations.
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?
A single sentence with zero wasted words. The verb is front-loaded, and the resource is immediately clear. It is appropriately concise for a simple tool.
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?
For a simple tool with annotations covering safety and schema covering parameters, the description is minimally adequate. However, it omits any mention of return behavior (despite an output schema existing) and does not clarify that the expense must already exist, which could be inferred from the parameter but is not explicit.
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 clear descriptions for both parameters ('Comment text to post.' and 'Id of the expense to comment on.'). The description adds no additional meaning; this is the baseline for full schema coverage.
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?
The description states a clear verb ('Post') and resource ('comment on an expense'), distinguishing it from siblings like delete_comment. It is specific but lacks any additional nuance (e.g., whether it appends or replaces).
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 is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., expense must exist) or exclusions, leaving the agent to infer context from the parameter schema.
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?
Annotations already disclose that the operation is non-read-only, idempotent, and non-destructive (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds no extra behavioral context beyond the action itself, such as idempotency or side effects, but does not contradict the annotations. Since the bar is lower with annotations present, a 3 is appropriate.
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?
The description is a single, efficient sentence with zero filler. The action and object are front-loaded, achieving maximum clarity in minimal space.
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?
For a simple one-parameter tool with annotations covering safety and an output schema present, the description is minimally adequate. However, it omits usage guidance and potential behavioral nuances (e.g., what happens if the expense is already restored), leaving some gaps in completeness for an agent to navigate without further context.
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 description coverage is 100%, and the schema already fully documents expense_id as 'Id of the previously deleted expense to restore.' The description adds no additional semantics beyond what the schema provides, so the baseline of 3 applies.
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?
The description states a precise verb ('restore') and resource ('previously deleted expense'), clearly distinguishing this from sibling tools like delete_expense and create_expense. It is unambiguous about what the tool does, though it could add a bit more specificity about what restoration entails (e.g., restoring to active status).
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 is given about when to use this tool versus alternatives, nor any prerequisites (e.g., whether the expense must be soft-deleted, or if there are restrictions on which deleted expenses can be restored). The agent is left to infer the usage context from the name and description alone.
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?
Annotations already disclose destructiveHint and idempotentHint. The description adds 'permanently,' which clarifies irreversibility, but it does not mention confirmation behavior, cascading effects, or failure semantics beyond what the schema already hints at.
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?
The description is a single, front-loaded sentence with no filler. It efficiently states the action and resource without repeating schema or annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with a full input schema and an output schema, the description is sufficient. The annotations carry the destructive/idempotent behavior, and the schema documents the confirm and expense_id parameters.
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 description coverage is 100%, with expense_id described as 'Id of the expense to delete' and confirm as 'Skip the confirmation step and delete immediately.' The description adds no additional parameter-level meaning, so the baseline of 3 applies.
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?
The description uses a specific verb and resource: 'Permanently delete an expense.' The word 'permanently' also differentiates it from the sibling tool 'undelete_expense' by signaling irreversibility.
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?
The description gives no when-to-use guidance and does not contrast with related tools like 'update_expense' or 'undelete_expense.' The word 'permanently' implies finality, but no explicit alternative or exclusion is 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?
Annotations already convey non-read-only, idempotent, and non-destructive behavior. The description adds the 'previously deleted' precondition but does not disclose what the restore operation entails (e.g., restoring members, expenses, or group settings). It contradicts no annotations.
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?
A single, front-loaded sentence communicates purpose with no redundant words. Every word earns its place, and the tool's core intent is immediately visible.
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?
For a simple one-parameter tool with an output schema and useful annotations, the description is nearly complete. It would benefit from a note about what is restored (e.g., all associated data) or any time limits, but nothing essential is missing for basic invocation.
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 description coverage is 0%, and the description does not explicitly explain the group_id parameter. However, the parameter name is self-explanatory, and the description's phrase 'previously deleted group' clarifies that group_id refers to a deleted group to restore. This provides partial compensation but not full parameter-level guidance.
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?
The description uses a specific verb ('Restore') and a specific resource ('previously deleted Splitwise group'), making the tool's purpose immediately clear. It also distinguishes itself from siblings like delete_group and undelete_expense by naming the exact resource and state.
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?
The description clearly states when to use the tool: to restore a previously deleted Splitwise group. It does not explicitly discuss when not to use it or name alternatives, but the context is unambiguous enough for an agent to select it appropriately.
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?
Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds useful context by specifying the operation returns groups the authenticated user belongs to and that all such groups are included. It does not describe unnecessary behavioral details beyond that, but given the strong annotations and simple read-only nature, this is adequate.
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?
A single sentence with no filler or redundancy. The core action, resource, and scope are front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only listing tool with a rich output schema and comprehensive annotations, the description fully covers what an agent needs. There are no missing prerequisites, inputs, or side effects to disclose.
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?
The tool has zero parameters and an empty schema, so the schema requires no explanation. The description reinforces that the tool takes no input and operates on the authenticated user's own groups. This matches the baseline for parameterless tools.
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?
The description uses a specific verb ('List'), a clear resource ('Splitwise group'), and scopes it to 'every' group the authenticated user belongs to. This clearly distinguishes it from sibling tools like get_group (single group) and create_group (creating groups).
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?
The description implies when to use the tool: whenever you need the full list of groups for the current user. However, it does not explicitly mention alternatives or exclusions, such as 'use get_group for a single group' or 'use create_group to add a group.' The usage context is clear but not explicitly contrasted with sibling tools.
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?
The annotations already mark the operation as non-read-only and non-idempotent, so the description does not need to restate that. It adds valuable behavioral detail beyond the annotations: failed member additions do not roll back the entire group, and the error reports which members failed so they can be retried via `manage_group_members`. This is a non-obvious partial-failure behavior that an agent should know before calling.
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?
The description is two short paragraphs with no filler. The core action is front-loaded in the first sentence, and the important failure caveat is separated into the second paragraph. Every sentence adds meaningful guidance.
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?
Given the two parameters, the rich input schema, and the presence of an output schema, the description is mostly complete. It covers the main purpose, optional membership, and the partial-failure behavior. A minor gap is not explicitly stating that adding members to an existing group should use `manage_group_members`, though the 'initial members' wording and retry reference imply as much.
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?
The tool-level description adds little parameter detail beyond calling members 'initial members' and alluding to malformed invites. However, the input schema compensates with structured descriptions for `GroupMemberInput`, `user_id`, `email`, `first_name`, and `last_name`, so an agent reviewing the schema can understand the member modes. The description does not shoulder the full burden, but the schema largely fills the gap.
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?
The description states a specific verb and resource: 'Create a new Splitwise group and optionally add its initial members.' It also names a related sibling tool, `manage_group_members`, for handling failed member retries, which sharpens the boundary between creating a group and later managing its members.
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?
The description clearly establishes when to use the tool: when creating a new group, with optional initial member adds. It also explicitly points to `manage_group_members` as the retry path for members that failed during creation, giving a concrete alternative for that scenario. It does not discuss broader exclusions, but the context is clear enough.
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?
Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so the safety profile is established. The description adds valuable behavioral context about the response contents: it returns a single expense's full detail, including splits and the comment thread, which is not inferable from the schema alone.
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?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the action, the resource, and the key content of the response.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, existing annotations, and an output schema, the description is complete enough for an agent to invoke it correctly. It identifies exactly what will be returned and does not need to explain return values because an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the expense_id parameter, but it does not mention it at all. The parameter name and type are self-explanatory to some degree, but the description adds no meaning beyond the schema's field name and integer type.
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?
The description states a specific verb ('Fetch'), a specific resource ('one expense'), and the scope of what is returned ('full detail, including its splits and comment thread'). This clearly distinguishes it from list_expenses, which retrieves multiple expenses, and from the mutation siblings.
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?
The description makes the intended use clear: call this tool when you need the full detail for a single expense. It does not explicitly name alternatives or exclusion conditions, but the 'one expense' phrasing and the tool name provide sufficient context for 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the mutation risk is covered. The description adds genuinely useful behavioral context: changing the amount requires also supplying split, and the tool will not guess how to redistribute. It does not mention the confirmation step, though the schema documents the 'confirm' parameter, so this is a minor gap rather than a serious omission.
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, no filler. The first sentence front-loads the tool's purpose and target fields, and the second explains a critical constraint. Every sentence 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?
Given the rich input schema, 100% parameter coverage, and annotations covering safety, the description is nearly complete. It could explicitly mention the confirmation workflow or the destructive nature of updates, but the schema and annotations already carry that information. For an 8-parameter update tool, this is adequate and slightly above the minimum viable bar.
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 description coverage is 100%, so the description has little burden to explain parameters. It does reinforce the amount-requires-split rule, but that rule already appears in the amount parameter's schema description. No additional parameter-level semantics are provided beyond what the schema already offers.
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?
The description states a specific verb ('Update') and a specific resource ('an existing expense'), and enumerates the mutable fields: description, amount, split, date, or category. This makes it immediately distinguishable from sibling tools like create_expense, delete_expense, get_expense, and list_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?
The description clearly implies the tool is for modifying an existing expense rather than creating, deleting, or viewing one. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to choose this tool correctly.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is fully covered. The description adds minimal context by clarifying the operation targets the authenticated server account, but it does not disclose additional behavioral details such as authentication failure behavior or response shape.
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?
A single, grammatically complete sentence with no filler or redundancy. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, zero parameters, strong safety annotations, and the presence of an output schema, the description is sufficient for an agent to select and invoke this tool correctly. No additional contextual information is necessary.
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?
The tool has zero parameters, so the baseline is 4 per the rubric. The description correctly implies no inputs are needed, and there are no parameter semantics left unexplained.
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?
The description uses a specific verb ('Return') and a clear resource ('the profile of the Splitwise account this server is authenticated as'). This unambiguously distinguishes it from sibling tools that target expenses, groups, or friends.
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?
The description clearly indicates the tool's purpose: retrieving the current authenticated account's profile. While it doesn't explicitly state exclusions or alternatives, none of the sibling tools serve this identity-focused role, so the usage context is clear without needing further 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?
Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds valuable behavioral context by disclosing that results include current members, that group_name is case-insensitive, and that lookup is scoped to the caller's groups. It does not state precedence when both parameters are supplied, but this is a minor gap given the simple 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?
The description is two sentences with no redundancy. The primary purpose is front-loaded, and the parameter guidance is concise and directly actionable.
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?
Given the low complexity, rich annotations, and presence of an output schema, the description is nearly complete. The only notable missing piece is behavior when both group_id and group_name are provided or when both are omitted, which could be clarified.
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?
With 0% schema coverage, the description compensates by explaining group_id as an exact lookup and group_name as a case-insensitive substring match. It does not specify behavior when both parameters are provided or when neither is provided, but it does assign meaningful semantics to both parameters.
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?
The opening sentence states a specific verb and resource: 'Fetch a single group's detail, including its current members.' This clearly distinguishes the tool from list_groups and other sibling operations that operate on different entities.
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?
The description clearly explains the two lookup modes and the scope of group_name lookup, which tells an agent how to use the tool correctly. It does not explicitly name alternatives or exclusions, but the context is clear enough for selecting this tool over list_groups or manage_group_members.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds non-obvious behavior: pagination via limit/offset and the instruction to check has_more rather than assume completeness. No contradiction with annotations.
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 compact sentences are front-loaded with the core purpose, then scoping rules, then pagination. Every sentence carries unique information with no filler.
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?
For a listing tool with an output schema and read-only/idempotent annotations, the description covers purpose, default scope, scoping constraints, and pagination. The only minor omission is the dated_after/dated_before filters, but they are optional and reasonably inferable from their names.
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?
With 0% schema description coverage, the description carries the parameter-semantics burden. It explains group/friend scoping, the mutual-exclusivity rule, and limit/offset meaning, but it omits dated_after and dated_before, leaving those two parameters to rely on their names alone.
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 opens with a specific verb and resource, 'List expenses', and immediately qualifies scope ('optionally scoped to one group or one friend', otherwise 'whole account'). This distinguishes it from single-expense getters like get_expense and from group/friend listing siblings.
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?
It gives concrete usage constraints: pass at most one of group_id/group_name or friend_id/friend_name, and states that omitting all filters returns account-wide expenses. It doesn't explicitly name sibling alternatives like get_expense, but the guidance is clear enough for correct selection.
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?
Annotations already indicate destructiveHint=true, but the description adds crucial behavioral details: that removal is destructive, requires confirmation unless confirm=true, and that adding executes immediately. It also explains that first_name/last_name can be used for new invites or disambiguation. This goes beyond the annotation's bare hint, providing practical operational transparency.
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?
The description is tight and well-organized. The primary action is stated first, followed by identification schemes and behavior nuances. Every sentence adds value without redundancy or fluff, making it easy for an agent to parse quickly.
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?
Given the tool's complexity (8 parameters, dual actions, destructive behavior) and the existence of an output schema, the description is essentially complete. It covers identification, add/remove behavior, confirmation, and invite specifics. It could mention response or error handling, but with an output schema present, that is not required. Overall, it provides enough context for correct invocation.
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?
With schema description coverage at 0%, the description carries the full burden of explaining parameters. It does so well: it explains how to specify the group (group_id or group_name) and member (user_id or email), the role of first_name/last_name, and the confirm parameter's function. The action parameter is self-explanatory via the enum. Some nuances (e.g., behavior when both group_id and group_name are provided) are not addressed, but the core semantics are well-covered.
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?
The description clearly states the tool's purpose: 'Add or remove a member of a Splitwise group.' It names the specific verb and resource (group member management) and is readily distinguishable from sibling tools like create_group or delete_group, which handle group-level operations.
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?
The description explains how to identify the group and member (via group_id/group_name and user_id/email), and clarifies the difference between add and remove, including the confirm flag for removal. It does not explicitly name alternative tools, but the guidance for when to use add vs. remove is clear and sufficient for an agent to select this tool appropriately.
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?
Annotations already indicate readOnlyHint=false, so the write nature is covered. The description adds genuinely useful behavioral context beyond annotations: the exclusive group/friend requirement and how participant names are resolved against group members or the authenticated user's friends.
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 tight paragraphs with no filler. The first sentence front-loads the action and scope, and every subsequent sentence conveys a constraint an agent must know to call the tool successfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter tool with complete schema descriptions and an output schema, the description covers the two non-obvious invariants that would otherwise cause failed calls: the exclusive group/friend target and participant resolvability. Required parameters and defaults are already documented in the schema.
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 description coverage is 100%, so the baseline is 3. The description adds value by expressing the exactly-one constraint among group_id/group_name/friend_id/friend_name and explaining how name-based participant resolution works—semantics not captured by the schema's individual parameter descriptions.
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?
The description names the exact operation (create), the resource (expense), and the scope (split among a group or a single friend). This clearly differentiates it from sibling tools like get_expense, update_expense, and delete_expense without needing to inspect the schema.
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?
It clearly establishes the creation context and states the hard constraint that exactly one group or friend identifier must be provided. It doesn't explicitly name alternative tools for when not to use it, but the verb 'Create' plus the resource makes the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description explains meaningful behavior: previews and confirmation are id-only because Splitwise cannot fetch a comment by id, and repeated deletion is treated as a no-op rather than a hard failure. This clarifies the idempotentHint annotation and gives an agent accurate expectations for edge cases.
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?
The description is front-loaded with the core action and then provides two tightly focused pieces of behavioral context. Every sentence adds necessary information without redundancy or unrelated detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, together with the annotations and output schema, gives an agent everything needed to call this tool correctly: the destructive nature, idempotency behavior, confirmation semantics, and the limitation around previewing. No critical operational detail is missing.
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?
The input schema already documents both comment_id and confirm with 100% coverage, so the description does not need to redefine them. It adds context about the confirmation flow, but the parameters themselves are simple and well-covered by 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?
The description opens with 'Permanently delete a comment,' which is a specific verb plus resource and clearly states the tool's destructive purpose. It also distinguishes itself from delete_expense by noting that no endpoint exists to fetch a single comment by id, making the tool's behavior unique among siblings.
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?
The description clearly situates this tool as the way to delete comments and contrasts it with delete_expense, which helps an agent choose between those two destructive operations. It does not explicitly enumerate all when-to-use/when-not-to-use cases, but the context is clear enough for correct selection.
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?
The annotation already declares destructiveHint=true and idempotentHint=true. The description goes beyond this by explaining exactly how idempotency works: calling again on an already-deleted group by ID is a no-op, but by name it is not. It also discloses the confirmation requirement when confirm=false. This adds valuable behavioral context that the annotations alone do not provide.
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?
The description is moderately sized but every sentence contributes unique value: purpose, identification, confirmation, alternative tool, and idempotency edge cases. It starts with the core action and flows logically. It could be slightly more concise, but it is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, idempotent tool with a confirmation mechanism, this description covers all necessary aspects: how to identify the resource, the confirmation behavior, the difference in handling already-deleted groups by ID vs name, and the restoration alternative. Since an output schema exists, return value details are not required here. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage (0%), so the description carries the full burden of explaining parameters. It does so thoroughly: group_id and group_name are explained as identification methods with different post-deletion behaviors, and confirm is explained as controlling whether the action previews or directly deletes. This fully compensates for the lack of schema descriptions.
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?
The description opens with a clear, specific verb and resource: 'Permanently delete a Splitwise group.' It explicitly distinguishes itself from undelete_group, which is a sibling tool, and explains the confirmation behavior. This eliminates ambiguity about what the tool does and how it differs from related operations.
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?
The description provides clear context for when to use this tool: to delete a group, with the option to preview before deletion. It explicitly mentions undelete_group as the alternative for restoration, and explains the behavioral difference when identifying by group_id vs group_name. While it doesn't say 'do not use this if...', the guidance is sufficient for an agent to make an appropriate selection.
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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive traits. The description adds meaningful behavioral context by stating it returns current balances, beyond what annotations alone convey.
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?
The description is one sentence, front-loaded with the action and resource, and includes the key output detail ('current balances') without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, parameterless, and has rich annotations plus an output schema. The description supplies the essential scope and return-value context, leaving no critical gap for an agent to invoke it correctly.
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?
The tool has zero parameters, so the description bears minimal burden. Schema coverage is 100% and the description adds no unnecessary parameter details, which is appropriate for a parameterless tool.
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?
The description uses a specific verb ('List') with a precise resource ('every Splitwise friend of the authenticated user') and specifies the included data ('with current balances'). This clearly differentiates it from sibling tools like list_groups or list_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?
The description implies the use case: retrieving the authenticated user's friends and their current balances. It does not explicitly name alternatives or exclusions, but the context is clear and no misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses non-obvious behavior: the settlement is actually recorded as an ordinary expense with a specific owes/pays split, and Splitwise's UI will display it as a regular expense rather than a true payment. This is substantial, non-obvious behavioral context that annotations alone do not provide.
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?
The purpose is front-loaded in the first sentence, and the follow-up paragraph explains the important Splitwise workaround. The second paragraph is somewhat long but earns its place because the behavior it describes is non-obvious and critical for correctly understanding the tool's effect.
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?
For a mutating tool with sparse annotations, the description covers the essential call constraints and the most important behavioral caveat. An output schema exists, so return values need not be described. Minor gaps like permission failure behavior are not addressed, but the tool is sufficiently complete for correct invocation.
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%, so baseline is 3. The description adds meaningful cross-parameter semantics by requiring exactly one identifier per side and explaining name/id resolution against group members or the authenticated user and friends. This is valuable beyond the schema's individual parameter descriptions.
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?
The description clearly states the tool records a payment between users and settles part of a balance. It further distinguishes itself from create_expense by explaining that Splitwise's payment flag is not exposed, so this tool exists specifically for the settle-up case.
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?
The description gives explicit input constraints: exactly one from_user_id/from_user_name and one to_user_id/to_user_name must be provided, and resolution depends on whether a group is supplied. It also references create_expense as the overlapping alternative and explains why it is unsuitable, providing actionable selection guidance.
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

splitwise-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![splitwise-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/sarathfrancis90/splitwise-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sarathfrancis90/splitwise-mcp)

Score Badge

Copy to your README.md:

[![splitwise-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/sarathfrancis90/splitwise-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sarathfrancis90/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/sarathfrancis90/splitwise-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server