splitwise-mcp

Server Quality Checklist

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

Latest release: v2.4.0
Disambiguation5/5
Each tool maps to a distinct resource and action (friends, groups, expenses, comments, receipts), so there is no real overlap or ambiguity. Even similar pairs like get_current_user vs get_user are clearly differentiated by their descriptions.
Naming Consistency5/5
All tools follow a consistent sw_ verb_noun pattern, e.g. sw_create_expense, sw_list_groups, sw_delete_comment. The naming convention is uniform and predictable across all 26 tools.
Tool Count3/5
26 tools is slightly above the 16-25 'heavy' range, but the count is justified by the breadth of the Splitwise API. The tool set is organized and coherent, though agents may face a large surface to scan.
Completeness4/5
The core Splitwise workflows are well covered: friends, groups, expenses, comments, receipts, notifications, currencies, and categories. Minor gaps like updating a group or fetching a single friend's details exist, but they are not likely to block common workflows.
Average 4.2/5 across 26 of 26 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 15 of 15 community issues answered or closed in the last 6 months
- 102 commits in the last 12 weeks
- Last stable release on September 5, 2026
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotation destructiveHint=true. Critically, it omits the confirmation workflow (the 'confirm' parameter must be true, otherwise a preview is returned) and any details about side effects. The annotation suggests destructive potential, but the description does not explain why or how.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, consisting of a single sentence with no extra details. While it is not verbose, it is under-specified, omitting important information about the confirmation requirement and parameter behavior. It is concise but not adequately informative.
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?
Given the tool has 4 parameters, includes a confirmation/preview mechanism, and lacks an output schema, the description is far from complete. It does not explain the preview flow, the group_type options, or the implications of simplify_by_default. The schema covers some of this, but the description itself provides minimal context for an agent deciding to invoke the tool.
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 schema already documents each parameter. The description adds no additional meaning or context for the parameters, but the schema is sufficient. Baseline of 3 is appropriate.
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 clearly states the action ('Create') and the resource ('a new Splitwise group'), making the tool's purpose unambiguous. However, it does not differentiate from sibling tools like sw_get_group or sw_delete_group, though the verb itself provides sufficient distinction.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. There is no context about when someone would choose to create a group versus simply retrieving or updating an existing one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Update' without revealing critical traits. The schema shows a 'confirm' parameter that 'Must be true to proceed. Without this, the tool returns a preview.' This preview/mutation toggle is a major behavioral nuance that the description omits, making it misleading for an agent invoking the 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?
The description is a single concise sentence, efficiently conveying the purpose and the critical id constraint without any fluff. Every word earns its place, making it appropriately sized and front-loaded.
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?
Given the tool has 8 parameters, no annotations, no output schema, and only 25% schema coverage, the description is incomplete. It fails to mention the confirm/preview mechanism, the specific updatable fields, or what happens on success. An agent would lack essential context to use the tool correctly, especially the required confirm=true behavior for an actual update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (id and confirm have descriptions). The description adds no parameter-level detail beyond the schema; it generically says 'profile fields' without enumerating which fields (email, locale, password, names, currency) are updatable. It also repeats the id constraint already in the schema, providing no additional semantic value.
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 function with a specific verb and resource: 'Update the current user's profile fields.' This distinguishes it from sibling tools like sw_get_current_user (read) and sw_update_expense (different resource). The constraint 'id must be the current user's id' further scopes the tool precisely.
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 clear this tool is for updating the current user's own profile by requiring the id to be the current user's id. This implies you should not use it for other users. However, it does not explicitly state when not to use it or mention alternatives like sw_get_current_user for reading, so it is clear context without explicit exclusions.
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?
The readOnlyHint annotation already covers the safety profile, and the description is consistent with it. However, the description adds little behavioral detail beyond mentioning the returned data; it does not disclose response size considerations, error behavior, or other operational traits.
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, clear sentence with no wasted words. The core purpose and scope are front-loaded and immediately understandable.
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 read-only single-group retrieval tool, the description plus the fully documented input schema gives enough context to call it correctly. The absence of an output schema is partially mitigated by the description naming the returned content, though explicit guidance about alternatives would improve completeness.
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 input schema fully documents the 'id' and 'view' parameters. The tool description itself adds no parameter semantics, so the baseline of 3 is appropriate.
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 verb ('Get'), resource ('details of a single Splitwise group'), and key contents ('all members and balances'). It distinguishes itself from sibling tools like sw_list_groups by emphasizing a single group.
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 it is for retrieving one group, which differentiates it from sw_list_groups, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. Usage context is clear only by inference from the wording.
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?
With no annotations provided, the description carries the full burden. It discloses the core behavioral trait (restoring a soft-deleted group, implying a state change), but does not mention permissions, error cases, idempotency, or what happens if the group is not soft-deleted.
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 concise sentence that fully conveys the purpose without wasted words. It is appropriately sized for a simple 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?
For a single-parameter tool with no output schema, the description is largely complete: it explains what the tool does and what the parameter is. It lacks detail on return values or error behavior, but given the simplicity, this is a minor gap.
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 the 'id' parameter described as 'Group ID to restore'. The tool description adds no additional semantic detail, so it meets the baseline of 3 but does not exceed it.
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 action ('Restore') and the resource ('soft-deleted Splitwise group'). It is specific and distinguishes this tool from siblings like sw_delete_group and sw_undelete_expense by targeting groups specifically.
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 phrase 'soft-deleted' implies the tool is for restoring groups that were previously soft-deleted, providing implicit usage context. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It does not mention the confirm requirement (Must be true to proceed) or that without confirm the tool returns a preview. It also does not clarify any permissions, side effects, or whether the action is reversible. This is a significant gap for a mutating 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, no redundancy. Every clause adds value: the action, the parameter preference, the fallback method, and the pointer to a sibling tool. This is a model of concise, structured description.
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?
The tool has 6 parameters and no output schema or annotations. The description explains the core action well but omits the confirmation behavior and return flow (preview without confirm). While the schema partially covers this, the description itself leaves out critical execution context, making it merely adequate.
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 50%, so the description compensates meaningfully by explaining the two parameter combinations: user_id alone, or first_name + last_name + email. It also highlights that user_id is preferred, adding practical guidance beyond the schema's bare field 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 verb ('Add') and resource ('user to a Splitwise group'), and distinguishes the two identification methods. It is immediately obvious what this tool does and it naturally contrasts with the sibling 'remove user from group'.
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 explicit guidance on when to use user_id versus first_name/last_name/email, and references sw_list_friends as a helper to resolve names. It does not explicitly state when not to use this tool or mention alternatives like sw_create_friend, but the provided context is clear and actionable.
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 are provided, so the description carries the full burden. It does disclose that the tool restores soft-deleted expenses, which is a key behavioral trait. However, it lacks details about permissions, error conditions, idempotency, or what happens if the expense is not already soft-deleted, which would be valuable for a restore 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 a single, succinct sentence that front-loads the action verb 'Restore' and includes only essential information. There is no redundancy or irrelevant content.
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?
The tool is simple with one parameter and no output schema. The description explains the core purpose but omits details about return values, failure behavior, or prerequisites beyond the 'soft-deleted' state. Given no annotations, more contextual information would improve completeness, but the description is not critically incomplete.
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 fully documents the single 'id' parameter (100% coverage) with a description. The tool description adds no additional parameter meaning, which is acceptable given the high schema coverage. 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 'restore' and specifies the resource as a 'soft-deleted Splitwise expense,' clearly distinguishing it from sibling tools like sw_undelete_group and sw_delete_expense. It unambiguously states what the tool does.
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 when to use this tool: when a Splitwise expense has been soft-deleted and needs to be recovered. It does not explicitly mention alternatives, but the resource specificity (expense vs. group) differentiates it from sibling sw_undelete_group, providing clear contextual guidance.
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?
The readOnlyHint annotation already signals safety, and the description's 'Get' aligns with that. The description adds the scope 'all comments' but does not disclose response shape, ordering, or pagination; this is a minor gap given the annotation coverage.
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 with no filler. Every word contributes to identifying the operation and resource.
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 read-only tool with fully documented parameters and a readOnlyHint, the description is largely sufficient. It could briefly indicate that the response is a list of comments, but the tool name and description make that reasonably inferable.
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 input schema already documents expense_id and view. The description adds no additional parameter meaning beyond the schema, matching the baseline for fully covered 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?
Description states a specific verb ('Get'), resource ('all comments'), and scope ('on a Splitwise expense'). This clearly distinguishes it from the sibling comment tools, which create or delete comments.
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 it clear this is the read tool for comments on an expense, so an agent can infer when to use it versus create_comment or delete_comment. It does not explicitly state when not to use it, but no competing read-comments sibling exists.
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?
The description adds little behavioral detail beyond the readOnlyHint annotation: it conveys single-record lookup and 'full details' but does not mention error behavior, the default compact response, or other runtime traits. With readOnlyHint=true already covering safety, 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, front-loaded sentence with no wasted words. It names the operation, resource, and key identifier efficiently.
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 read-only getter with fully documented parameters and readOnlyHint, the description is nearly sufficient. It lacks explicit alternative routing and response/error hints, but the schema's detailed view semantics compensate for most missing 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%, so both parameters are already fully documented in the schema. The description only restates the id-based lookup and adds no meaning beyond the detailed view enum explanation, so the baseline 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 states a specific verb ('Get'), a precise resource ('a single Splitwise expense'), and the lookup key ('by id'). This clearly distinguishes it from list-oriented siblings like sw_list_expenses and from mutating expense tools.
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 phrase 'single... by id' gives clear context: use this when you need details for one known expense. However, it does not explicitly name alternative tools or state when not to use it, such as using sw_list_expenses for multiple expenses.
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=true, and the description is consistent with that, adding scope ('current user') and recency ('recent') context. However, it does not disclose output format, ordering, pagination, or how the view parameter changes behavior beyond what the schema already states.
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 sentence with no filler. It front-loads the action and resource, and every word contributes to the agent's understanding of what the tool does.
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?
This is a simple, read-only retrieval tool with one fully documented optional parameter, so the description is mostly sufficient. The main gap is that there is no output schema and the description does not clarify the return shape, but 'notifications' is understandable enough for 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 100%, and the only parameter, 'view', is fully documented with enum values, defaults, and response-shape details. The tool description adds no parameter-level meaning, so the schema carries the burden and the description meets the baseline.
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: 'Get recent Splitwise activity notifications for the current user.' It clearly identifies the tool's target and scope, and none of the sibling tools handle notifications, so there is no ambiguity with alternatives.
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: retrieving the current user's recent activity notifications. It does not explicitly discuss alternatives, but no sibling tool serves this purpose, so the context is sufficient for an agent to select 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?
The annotations already declare readOnlyHint=true, and the description adds no behavioral details beyond listing/searching and optional filters. It does not describe response behavior or pagination, but the schema covers limit and offset; there is no contradiction.
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 short sentences, front-loaded with the purpose, and no wasted words. 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?
For a read-only list tool with nine fully documented optional parameters, the description plus schema is largely sufficient. It could briefly note response shape or explicitly route users to sw_get_expense for individual expense details, but those are minor gaps.
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 schema already documents all nine parameters. The description reinforces group_id and date-range filtering, but mostly paraphrases what the schema already states.
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: 'List or search Splitwise expenses.' The plural 'expenses' and the mention of filters distinguish it from the single-record sibling tool sw_get_expense.
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?
'All filters are optional' and 'Use group_id to filter by group, dated_after/dated_before for date ranges' give clear, practical usage context. It does not explicitly exclude alternatives like sw_get_expense for single-record lookups, so it falls just short of a 5.
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 declare readOnlyHint=true, and the description adds the 'hierarchical' nature of the list, which is useful but limited. No additional behavioral context like pagination or structure is given, but the read-only trait is already covered by 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?
The description is two short sentences that directly state the purpose and practical usage. No filler or redundancy, 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?
The tool is simple with no parameters and a read-only annotation. The description adequately conveys what is returned (hierarchical categories) and how to use the result. It does not specify the exact structure, but that is acceptable for this minimal 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?
With zero parameters, the schema fully covers parameter semantics (100% coverage). The description adds value by explaining the purpose of the returned id, which indirectly supports the output usage rather than parameters. Baseline of 4 is appropriate for 0 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 description clearly states the tool retrieves a 'hierarchical list of Splitwise expense categories,' using a specific verb and resource. It differentiates from sibling tools which focus on groups, users, friends, and 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 provides explicit workflow guidance: 'Use the returned id as category_id when creating expenses.' This tells when to use the tool, though it does not mention exclusions or alternatives, which are not necessary here.
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 readOnlyHint annotation already establishes this as a safe read operation. The description adds useful behavioral detail: the compact default merges first_name/last_name into name, while view:'full' keeps them separate. This goes beyond what the annotation alone provides.
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 efficient sentences with no filler. The core purpose is front-loaded, and the behavioral note about compact/full is placed immediately after, giving the agent the most important call-shaping information up front.
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 read-only lookup with a detailed schema and readOnlyHint, the description plus schema is largely sufficient. It explains the response-shape distinction and required ID. It relies somewhat on the sibling reference for full shape understanding and omits error/not-found behavior, but those are minor for this tool.
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 fully explains the id and view parameters, including the compact/full response shape. The description largely restates the view behavior already present in the schema, so it adds limited new parameter meaning.
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: 'Get another Splitwise user's profile by id.' It also distinguishes itself from the sibling sw_get_current_user by emphasizing 'another' user, making the target resource unambiguous.
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 this tool is for fetching a different user's profile by ID, and references sw_get_current_user as a related alternative. However, it stops short of explicitly saying 'use sw_get_current_user for the current user' or providing when-not-to-use conditions.
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?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the detail that it returns both codes and units and that the currency_code is used for expense creation, but it doesn't disclose additional behavioral traits like return format or pagination. The annotation covers the safety profile, so this is adequate but not exceptional.
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: the first states the exact function, the second provides usage context. There is no filler or redundancy, making it highly concise and well-structured.
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 simplicity (no parameters, no output schema, readOnly annotation), the description fully covers what the tool does and how to use the result. It mentions the returned data (codes and units) and gives a concrete application, making it complete for its complexity.
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 there are no parameter semantics to explain. The schema is empty and fully self-descriptive. The description doesn't need to compensate, so the baseline score of 4 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 the specific verb 'Get' and clearly identifies the resource: Splitwise-supported currency codes and units. It is distinct from sibling tools that handle groups, users, expenses, etc., so the purpose is unambiguous.
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 actionable guidance: 'Use the currency_code value when creating expenses in non-default currencies.' This tells the agent when the retrieved data is relevant. It doesn't explicitly mention when not to use this tool or name alternatives, but there are no currency-specific siblings, so the context is clear.
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, and the description adds useful behavioral context: it lists all groups the current user belongs to, and it specifies the returned fields. It does not contradict the annotations and provides enough clarity for a read-only list 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?
Three sentences, each earning its place: the first states the action and scope, the second states the return shape, and the third gives a concrete use case. It is front-loaded and free of 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 description provides the essential context for calling this tool correctly: scope (current user), output fields (id, name, members), and a practical use case. The optional parameter is fully specified in the schema, and the read-only annotation covers safety. Nothing critical is missing for a list tool.
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% and the single optional 'view' parameter is already thoroughly documented in the schema, including its enum values and real-world size caveats. The description does not add parameter-level meaning, but the schema fully carries that burden, so the baseline of 3 is appropriate.
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 clear resource ('Splitwise groups') and scopes it to the current user. It also names the primary return fields (id, name, members), which distinguishes it from sibling tools like sw_get_group or sw_create_group.
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 explicitly states a concrete use case: 'Use this to resolve a group name to its id.' It also implicitly distinguishes itself from group-specific tools by covering all groups for the current user, though it does not explicitly name alternatives or list when-not-to-use conditions.
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?
The description goes well beyond the destructiveHint annotation by disclosing the dry-run preview behavior and the fact that no network call occurs without confirm:true. This is critical safety context that the annotation alone does not convey, making the tool's behavior highly transparent.
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 well-structured sentence that front-loads the primary action and then efficiently explains the safety mechanism. Every word earns its place, with no redundancy or 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 simple delete tool with no output schema, the description covers the operation, the confirm safety switch, and the network-call behavior. It could optionally mention the preview's content or permanent nature, but the destructiveHint annotation and the clear 'removes the friendship' statement provide adequate 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?
The input schema already provides complete descriptions for both parameters (id and confirm) at 100% coverage. The description restates the confirm semantics but does not add additional meaning beyond what the schema already offers. Therefore, a baseline score of 3 is appropriate.
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 precisely what the tool does: 'Remove a Splitwise friendship by user id.' It uses a specific verb (Remove) and resource (Splitwise friendship), clearly distinguishing it from sibling tools like sw_list_friends and sw_create_friend. The added confirm behavior further reinforces the tool's core purpose.
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 this is the tool to use for deleting a friendship and explicitly explains the two modes of use (dry-run without confirm:true, actual deletion with confirm:true). However, it does not name sibling alternatives or state exclusions, so it slightly falls short of full usage 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?
With readOnlyHint=true already covering the safety profile, the description adds genuinely useful behavioral context: the compact/full response shapes, the name-joining behavior (first_name + last_name joined), and the compatibility note that sw_update_user expects the full form. It discloses output-shape behavior beyond what the annotation states, without contradicting the read-only hint.
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?
Three sentences, with the purpose front-loaded and no filler. Each sentence earns its place: purpose, compact shape, full-shape rationale. It is slightly dense and partially overlaps with the schema's view description, but it remains efficient and readable.
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 optional enum parameter, a detailed parameter schema, and no output schema, the description covers everything an agent needs: purpose, return fields, view selection, and the downstream consumer (sw_update_user). No missing information would prevent a correct call or interpretation.
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% and the schema's view description is already detailed, so the baseline is 3. The description adds extra meaning beyond the schema by explaining WHY full mode matters — 'the form sw_update_user takes' — which ties the parameter choice to a concrete downstream workflow. That added rationale justifies the 4.
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 specific verb+resource: 'Get the authenticated Splitwise user's profile.' The word 'authenticated' immediately distinguishes it from the sibling sw_get_user, and the downstream-use note ('Use the returned id when building custom expense splits') reinforces its distinct role. This is as clear a purpose statement as the tool could have.
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 clear usage context — this returns the authenticated user's profile and the id is meant for building custom expense splits — and it explains when to choose view:'full' (when the raw record with separate first_name/last_name is needed for sw_update_user). It does not explicitly state when NOT to use it or direct the agent to sw_get_user for other users, so it falls just short of a 5.
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?
The annotation only states destructiveHint=true, but the description goes further by disclosing the dry-run behavior, the no-network-call guarantee without confirm, and the requirement for confirm to actually remove. This adds substantial behavioral context beyond the annotation.
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: first states the core action, second explains the confirm behavior. No fluff, front-loaded with purpose, and 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?
For a destructive tool with no output schema, the description covers the critical behavior (dry-run vs actual removal) that an agent must know. It doesn't describe the preview contents, but that's a minor gap. Overall, it's complete enough given the simplicity of the operation.
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 schema already documents all three parameters with 100% coverage. The description repeats the confirm behavior that the schema also mentions, but does not add extra meaning for group_id or user_id. Baseline of 3 is appropriate since schema does the heavy lifting.
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 action: 'Remove a user from a Splitwise group.' This is a specific verb+resource pair that distinguishes it from sibling tools like sw_add_user_to_group and sw_delete_group. The dry-run/confirm distinction is also included.
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 guidance on when to use confirm:true vs false, which is essential for safe usage. It does not explicitly mention alternatives, but the tool's name and purpose make it clear when to use it relative to siblings. The safety guidance is valuable and partially addresses usage.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It clearly explains the dry-run preview behavior, that no network call occurs without confirm:true, and that the users array replaces the entire split. These are important, non-obvious behavioral traits that go beyond the basic purpose.
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 three sentences long, front-loaded with the core purpose, and each sentence delivers essential information without redundancy. It is well-structured and easy to parse.
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 tool with 10 parameters and no output schema, the description covers the key caveats (dry-run, full split replacement) and provides enough operational context. It could be more complete by mentioning the return value, but the description is adequate for most update scenarios.
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 50%, and the description adds some value by reiterating the full-replacement semantics of the users array and the confirm behavior. However, several parameters (date, details, category_id, description, currency_code) lack schema descriptions and are not explained in the description. The general instruction 'any fields to change' partially compensates, but not fully.
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 edits an existing Splitwise expense, using a specific verb and resource. It distinguishes from siblings like create or delete by focusing on updating existing expenses, and the purpose is immediately obvious.
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 on when to use the tool: 'Provide expense_id and any fields to change.' It also includes crucial usage details about the full users array requirement and the dry-run vs confirm behavior. However, it does not explicitly state when not to use it or name alternative tools, though the sibling names make the alternatives apparent.
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 destructiveHint annotation, the description discloses that without confirm:true no network call is made and a dry-run preview is returned. This is critical behavioral information that adds significant value beyond the annotation.
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, front-loaded with the purpose, and contains no redundant or filler text.
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 mutation tool with no output schema, the description covers the core function, visibility, and confirmation requirement. It does not mention error conditions or return details, but these are not essential given the schema and 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?
Schema coverage is 100% with descriptions for all three parameters. The description reinforces the confirm parameter by explicitly stating 'makes NO network call' without confirm, adding detail not present in the schema description.
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 clearly states 'Add a comment to a Splitwise expense' with a specific verb and resource, and notes visibility to other participants. This distinguishes it from sibling tools like sw_get_comments and sw_delete_comment.
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 usage when a comment needs to be added and provides clear context, but it does not explicitly name alternative tools or exclusions. The confirm behavior is a key usage guideline.
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?
Beyind the destructiveHint annotation, the description discloses that without confirm:true a dry-run preview is returned and NO network call is made, while with confirm:true the friend is added. This reveals the gating mechanism and side effects, adding significant 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 two sentences long, front-loaded with the primary action, and contains zero redundant wording. Every phrase adds value.
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?
Covers the core behavior and side effects thoroughly for a 4-parameter tool, but doesn't describe the content of the dry-run preview. Given no output schema, a brief note on the preview would improve completeness, but it's not critical.
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 semantics for confirm by explaining the network-call behavior, which is not fully captured in the schema description. It reinforces user_email's purpose but doesn't over-specify.
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 ('Add') with a clear resource ('Splitwise friend') and method ('by email, sends invite'). It explicitly distinguishes the dry-run vs actual behavior, making it distinct from sibling tools like sw_list_friends or sw_delete_friend.
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 when to use confirm:true vs false, providing key usage context. It doesn't explicitly mention alternatives, but the sibling list and the purpose statement make the intended use obvious.
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?
Annotations already declare readOnlyHint and idempotentHint, but the description adds meaningful behavioral detail: it resolves credentials the same way real tools do, makes exactly one authenticated request, reports the credential source, and never returns the credential itself. This goes well beyond the annotation hints and gives agents an accurate picture of side effects and privacy behavior.
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 compact and front-loaded: the first sentence states the core action, the second lists the reported outcomes, the third gives usage and safety. Each sentence earns its place, though the output enumeration could be slightly tightened without losing clarity.
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?
Despite having no output schema, the description fully covers the return payload (credential source, acceptance, round-trip time, plain-English hint), the failure modes it distinguishes, the invocation trigger, and the read-only safety guarantee. For a zero-parameter diagnostic tool, nothing essential is missing.
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 zero parameters and 100% schema description coverage, the baseline is 4. The description adds value by clarifying that the implicit credential is resolved through the real tool path and is never returned, which addresses the only meaningful 'parameter' in this tool's context.
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 a specific verb-resource pair: it resolves the credential exactly as real tools do and makes one authenticated request to secure.splitwise.com. It clearly distinguishes itself from the sibling CRUD tools by being the diagnostic/healthcheck operation, so an agent can select it without opening schemas.
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 explicitly states when to use it: 'Call this when a real tool fails and you want to know which hop broke.' It implies the when-not by focusing solely on failure diagnosis, but it does not spell out exclusions or name alternative diagnostic tools, though no such sibling exists.
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, so the safe read nature is covered. The description adds useful behavioral context beyond that: the default 'compact' response shape, the joined name field, and the difference between compact and full views. It doesn't cover pagination or error behavior, but for this simple read-only list tool the disclosure is solid.
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 filler. The core function is front-loaded, the use case follows, and the compact/full distinction is explained in an organized way. Every sentence contributes information the agent needs.
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 list tool with one optional parameter, the description covers the operation, the use case, the default behavior, and the output shape for both views. Since there is no output schema, describing the returned fields is especially important, and this description does it well. The read-only annotation covers safety, so nothing essential is missing for correct invocation.
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?
Though the schema already describes the 'view' parameter well (100% coverage), the description adds concrete value: it explains the default value ('compact'), what the compact response contains (id, name, email, registration_status, balance), and that 'full' returns Splitwise's raw records with separate first_name and last_name. This goes beyond the schema by tying semantics to real output behavior.
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 specific verb and resource: 'List all Splitwise friends.' It clearly differentiates this tool from sibling tools like sw_create_friend and sw_delete_friend, and the use case—resolving a name to a user_id—adds further clarity. No ambiguity remains about what the tool does.
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 explicitly states when to use the tool: 'Use this to resolve a friend's name to a user_id before adding them to a group or building a custom expense split.' It gives clear context and downstream actions, though it doesn't explicitly mention when not to use it or name alternative tools. This is still strong practical guidance.
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?
With no annotations provided, the description fully discloses the critical side-effect behavior: 'Without confirm:true this returns a dry-run preview and makes NO network call; with confirm:true it creates the expense.' This alerts the agent to the mutation risk and the preview safety mechanism, going well beyond what schema alone provides.
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 concise sentences that cover purpose, usage modes, formatting constraints, and the critical confirm gate. Every clause earns its place with no fluff or repetition, making it easy to parse quickly.
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 create tool with no output schema and 10 params, the description distills the essential context: how to split, what cost requires, and the preview vs. real-creation distinction. The remaining optional params (date, currency_code, etc.) are adequately described in the schema, so the tool is fully usable with this description alone.
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 schema has 100% parameter coverage, providing baseline 3. The description Adds meaningful operational nuance by framing the split_equally vs users decision and reiterating the cost format. However, most parameter details (e.g., decimal strings, mutual exclusivity) already appear in the schema, so the added value is modest but helpful, warranting a 4.
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 'Create a Splitwise expense', which uses a specific verb and resource, clearly distinguishing it from sibling tools like sw_update_expense or sw_delete_expense. It also outlines the key operational modes, leaving no ambiguity about the tool's core function.
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 on how to use the tool: 'Use split_equally:true to split evenly... or provide a users array for custom per-person splits.' It also explains the crucial confirm:true gate. However, it does not explicitly name alternative tools or state when not to use this tool, so it misses the 'explicit alternatives' bar for a 5.
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?
Annotations only declare destructiveHint. The description adds critical behavioral context: without confirm:true it is a dry-run with NO network call, and with confirm:true it actually deletes. This significantly clarifies the tool's safety profile and goes beyond what annotations provide.
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, front-loaded with the core action, and every word earns its place. It is concise without sacrificing essential safety 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 two-parameter deletion tool with no output schema, the description is complete. It explains the destructive action, the dry-run behavior, and the confirm requirement. No critical missing information.
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 already describes both parameters (id, confirm) with 100% coverage. The description reinforces the relationship between confirm and execution, and adds the 'NO network call' nuance not present in the schema. This adds value 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's function: 'Delete a comment by id.' The verb is specific and the resource is unambiguous. It also distinguishes from sibling delete tools (group, friend, expense) by naming 'comment' explicitly.
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 operational context: the tool is for deleting a comment, and the confirm flag controls dry-run vs actual deletion. It does not explicitly discuss when to use this over alternatives, but the purpose is so specific that usage is implied. A 5 would require named exclusions or alternative comparisons.
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?
Despite the destructiveHint annotation, the description adds critical behavioral detail: it reveals that without confirm:true the tool makes NO network call and returns a dry-run preview. This is valuable context beyond the annotation, informing the agent that the destructive action is gated by a confirmation flag, thus preventing accidental deletions.
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 long and front-loads the core action. It earns its place by explaining the confirm flag's behavior without unnecessary fluff, making it both concise and structured effectively.
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?
With only two simple parameters, no output schema, and a clear explanation of both execution modes, the description is fully complete for the tool's complexity. It provides all necessary context for an agent to invoke the tool correctly, including the safe dry-run behavior.
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 schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds extra nuance by explicitly stating that without confirm:true, no network call is made, which goes beyond the schema's 'returns a preview' statement. This supplementary information clarifies the safe execution path, earning a 4.
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 'Soft-delete a Splitwise group,' a specific verb+resource phrase that clearly states the tool's function. It distinguishes from sibling tools like sw_undelete_group by explicitly marking this as the soft-delete action, leaving no ambiguity about what the tool does.
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 the two modes: without confirm:true it performs a dry-run preview with no network call, and with confirm:true it deletes. This provides clear guidance on how to invoke the tool safely, though it does not explicitly mention when not to use it or suggest alternative tools beyond the implicit contrast with undelete.
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 destructiveHint annotation, the description adds valuable behavior: it is a soft-delete (reversible), it returns {success: true}, and it makes no network call unless confirm:true is set. This explains the side-effect-free preview mode and the restoration path, going well beyond what the annotation alone conveys.
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 three sentences: first states the core action and target, second gives the return value and the restore alternative, third explains the confirm flag behavior. Every sentence carries essential information, with no filler or repetition.
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?
The description covers the purpose, return value, restoration, and the critical confirm gate. It lacks details about the exact structure of the dry-run preview or potential side effects on related data, but this is minor for a simple delete operation with no output schema. Overall, it provides sufficient context for an agent to use the tool 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 schema already provides descriptions for both parameters (100% coverage), so the baseline is 3. The description adds extra nuance for the confirm parameter by explicitly stating that without it there is a dry-run preview and NO network call, which is a meaningful behavioral detail not fully captured by the schema's description.
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 begins with 'Soft-delete a Splitwise expense by id', which is a specific verb+resource pairing that clearly identifies the operation. It distinguishes itself from siblings by explicitly mentioning sw_undelete_expense for restoration and by describing the dry-run vs. actual deletion behavior, making the purpose unambiguous.
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?
The description provides explicit guidance by naming sw_undelete_expense as the alternative for restoring an expense. It also clearly explains when to use the tool safely: without confirm:true it performs a dry-run with no network call, and with confirm:true it deletes. This gives the agent clear context on usage and safety.
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?
The description discloses meaningful behavioral details beyond the annotations: it writes files to disk by default, returns the file path, can inline bytes or extracted text, and can be disabled with write:false. It also warns about authentication issues with direct URL fetches. These are exactly the side effects and constraints the annotations do not capture.
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 dense but tightly organized: purpose first, then the 401 context, then parameter usage guidance, then filesystem behavior. Every sentence carries distinct information and none are wasted or redundant. The most important operational details are front-loaded.
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?
With six parameters and no output schema, the description still gives enough context to call the tool correctly: what it downloads, why direct URL fetching fails, how to get bytes or text, and when to avoid writing files. The schema covers remaining parameter mechanics like output_dir and size, so nothing essential is missing.
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, and the description adds extra semantic guidance on top of the schema. It clarifies when to use inline versus extract_text, that both work when the caller cannot see the server filesystem, and that write:false is for read-only or unreachable filesystem scenarios. This goes beyond the schema's per-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 opens with a specific verb and resource: 'Download the receipt image or PDF attached to a Splitwise expense.' It clearly distinguishes this tool from sw_get_expense, which returns receipt URLs rather than the receipt content itself. An agent can immediately tell what action this tool performs and what resource it operates on.
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?
The description explicitly tells the agent to use this tool instead of fetching receipt URLs directly, because those URLs return 401 without server credentials. It also gives concrete conditions for setting inline:true and extract_text:true, and when write:false is appropriate. This is strong when-to-use guidance with an explicit alternative path.
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/chrischall/splitwise-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/splitwise-mcp)

Score Badge

Copy to your README.md:

[![splitwise-mcp MCP server](https://glama.ai/mcp/servers/chrischall/splitwise-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/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/chrischall/splitwise-mcp'

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