splitwise-mcp

Server Quality Checklist

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

Latest release: v2.1.6
Disambiguation5/5
Every tool targets a distinct resource+action pair, even similar ones like sw_get_current_user vs sw_get_user are clearly separated by description. No two tools are easily confused.
Naming Consistency5/5
All tools consistently follow the sw_verb_noun pattern in snake_case, with a uniform sw_ prefix across all 25 tools. The vocabulary of verbs (list, get, create, update, delete, undelete) is consistent throughout.
Tool Count3/5
At 25 tools, the set sits at the upper boundary of the 'heavy' range. While each tool maps to a legitimate Splitwise API operation, the sheer number can be overwhelming for an agent to navigate effectively.
Completeness4/5
The surface covers most core Splitwise workflows: groups, friends, expenses, comments, notifications, currencies, and categories. However, there is no update_group tool, which is a notable gap for editing group details.
Average 4.1/5 across 25 of 25 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 6 community issues answered or closed in the last 6 months
- 84 commits in the last 12 weeks
- Last stable release on August 9, 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?
Annotations already declare readOnlyHint: true, so the read-only nature is known. The description adds no extra behavioral context (e.g., return format, ordering, or authentication needs), providing only minimal 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 a single, focused sentence with no redundancy or wasted words. It communicates the action and target effectively.
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 tool with one required parameter and no output schema, the description is mostly complete. It states the action and scope, but could have mentioned what the response contains (e.g., a list of comment objects with their details).
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 expense_id parameter described as 'Expense ID to get comments for'. The tool description adds no additional meaning beyond what the schema already provides, so 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 uses a specific verb ('Get') and resource ('comments on a Splitwise expense'), clearly distinguishing it from sibling tools like sw_create_comment or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear, but there is no explicit guidance on when to use this tool versus alternatives, or any mention of prerequisites. Usage is only implied by the tool name and description.
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, covering the safety profile. The description adds the context that it returns 'full details' but does not describe error handling, auth requirements, or response structure. This is adequate but not rich.
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 that is clear and front-loaded. Every word contributes to the meaning, 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, single-parameter read operation with a readOnlyHint, the description sufficiently communicates the purpose and return scope ('full details'). No output schema exists, but the description implies the return content well enough; minor gaps like error responses are not critical 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?
The input schema already provides 100% coverage of the single parameter 'id' with its type and description. The description simply reinforces 'by id' without adding new semantic meaning, so it meets the baseline for schema-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?
The description uses the specific verb 'Get' and clearly identifies the resource as 'full details of a single Splitwise expense' with the targeting mechanism 'by id'. This distinguishes it from sibling tools like sw_list_expenses and sw_update_expense.
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 usage when a specific expense id is known and full details are needed, but it does not explicitly mention when to use this over alternatives or provide exclusions. Sibling tools such as sw_list_expenses are not referenced, so the guidance is only implied.
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?
Annotation readOnlyHint=true already conveys safety. Description adds that the response includes members and balances, which is useful contextual info. No further behavioral details (e.g., error cases) are provided, but for a simple getter 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?
One concise sentence that states the purpose and key details, with no redundant or verbose language. 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 simple getter with one parameter and no output schema, the description sufficiently indicates the return content (all members and balances). It doesn't cover edge cases like not-found behavior, but this is not critical for basic usage.
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 describes the single parameter 'id' with a clear description ('Group ID'). The description does not add additional meaning beyond what the schema already provides, so 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?
Description clearly states the verb (Get), resource (details of a single Splitwise group), and specific content (members and balances). It distinguishes itself from sibling sw_list_groups by specifying '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?
No explicit when-to-use or alternative guidance, but the use of 'single' implies this is for retrieving one group rather than listing all. Context is clear but no exclusions or alternative recommendations are provided.
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?
The readOnlyHint annotation already declares this as a safe read operation. The description adds no further behavioral details such as authentication requirements, error behavior, or data access restrictions. It simply restates the action without going 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 a single sentence of seven words, front-loaded with the verb and resource. It contains no waste, and every word earns its place. This is an exemplary concise description.
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 one parameter and no output schema, the description adequately specifies what it does and what input is needed. It implies the return value (the profile) and is sufficient for an agent to invoke it, though it could mention potential limitations (e.g., need for friendship) if any exist; it is not incomplete enough to warrant a lower score.
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%—the parameter 'id' is already described as 'User ID'. The description merely says 'by id', adding no semantic value beyond what the schema provides. Baseline of 3 applies because the schema fully documents the parameter.
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 (Get), the resource (another Splitwise user's profile), and the required parameter (by id). It distinguishes from sibling tools like sw_get_current_user by specifying 'another', 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used to fetch a user's profile by ID, and the word 'another' implies it is not for the current user (contrasting with sw_get_current_user). However, it does not explicitly exclude alternatives or state when not to use it, so it stops 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 already declare readOnlyHint=true, so the read-only nature is covered. The description adds that all filters are optional, which is helpful but does not elaborate on return format, pagination behavior, or other operational traits beyond what the schema already implies. With annotations present, a score of 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 highly concise: two sentences that front-load the action ('List or search Splitwise expenses') and then clarify filter optionality. Every sentence earns its place with no filler or redundancy.
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 comprehensive parameter schema and a readOnlyHint annotation, the description sufficiently covers purpose and filter usage. It does not explicitly state the return type or pagination details, but these are reasonably implied by the list operation and the presence of limit/offset parameters. Overall, it is adequately complete for the tool's complexity.
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?
All 8 parameters have complete descriptions in the schema (100% coverage), so the description's mention of group_id and dated_after/dated_before simply echoes the schema. No additional meaning is added beyond the structured data, warranting the baseline score of 3.
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 'List or search Splitwise expenses,' using a specific verb and resource that clearly distinguishes this from sibling tools like sw_get_expense (single vs. multiple) and sw_list_groups (different resource). It unambiguously identifies 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by stating all filters are optional and highlighting group_id and date-range filters. However, it does not explicitly contrast with alternatives (e.g., sw_get_expense for a single expense) nor state when to avoid this tool, leaving usage guidance incomplete relative to the high standard.
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 covers the safety profile, and the description adds only the qualifier 'recent' without specifying the exact time window or response format. Since there is no output schema and the description does not disclose pagination or limits, it provides minimal additional 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?
The description is a single, concise sentence that immediately states the action and resource without any redundant words. It earns its place fully.
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 read-only tool with no parameters and no output schema, the description is adequate but leaves gaps: 'recent' is ambiguous, and it does not describe the return structure or any limits. More detail about what constitutes 'recent' or the notification payload would improve completeness.
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 input schema is empty, and the baseline for 0 parameters is 4. The description correctly does not need to explain parameters, and there is no missing information to compensate for.
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' clearly identifying the resource as 'recent Splitwise activity notifications' and scoping it to 'the current user'. This distinguishes it from all sibling tools, none of which mention notifications.
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 that this retrieves notifications for the current user, which is distinct from the other tools. However, it does not explicitly state when to use this versus alternatives or exclude specific scenarios, but the uniqueness of 'notifications' implies appropriate usage.
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.
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 adds the return structure (id, name, members) without contradicting the annotation. It does not provide additional behavioral context such as pagination or permission requirements, so the score stays at a mid level.
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 short sentences, front-loaded with the primary action, followed by return details and a practical use case. Every sentence earns its place with no redundant 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 list tool with no parameters, the description sufficiently conveys what it returns and why to use it. It lacks details like ordering or pagination, but these are unlikely to be critical. The return fields are explicitly listed, compensating for the absence of an output 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?
The tool has zero parameters, and the schema coverage is trivially complete. The description adds semantic scope by specifying 'all groups the current user belongs to', which conveys the filtering behavior even without a parameter. Baseline for zero-param tools is 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 clearly states the verb 'List' and the resource 'all Splitwise groups the current user belongs to', and differentiates from siblings like sw_get_group by specifying the collection scope. It also notes the return fields (id, name, members), making the tool's function 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 a concrete use case ('Use this to resolve a group name to its id'), which gives clear context for when to use this tool. It does not explicitly contrast with alternatives like sw_get_group, but the 'List all' language implies the distinction.
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.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint=true already establishes safety; the description adds behavioral detail by naming the exact return fields (id, first_name, last_name, email) and clarifying that the id is used for expense splits. It doesn't discuss errors or rate limits, but with the read-only annotation covering safety, this is sufficient.
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: the first states purpose and return fields, the second provides a usage guideline. No filler or redundancy.
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 zero-parameter read-only profile tool, the description covers what it does, what it returns, and a practical application. Absence of an output schema is mitigated by listing the fields. It's fully complete for the tool's 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 the description cannot add parameter semantics. The baseline for zero-param tools is 4, and no compensation is needed.
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 specifies a clear action ('Get the authenticated Splitwise user's profile') with explicit fields (id, first_name, last_name, email). The term 'authenticated' distinguishes it from sibling sw_get_user, which likely retrieves other users' profiles, and the sentence about building custom expense splits reinforces its role.
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 context for when to use it: to obtain the current user's id for building custom expense splits. It doesn't explicitly exclude alternatives, but the use case is clear enough, earning a 4 for clear context without exclusions.
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 signals a safe read operation. The description adds context by detailing the returned fields and the intended use case for name-to-ID resolution. It does not mention potential concerns like pagination or response size, but given the annotation coverage, the added context is sufficient.
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 action and output, the second provides a practical use case. Every word earns its place, with no repetition or 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?
This is a simple list operation with no parameters and no output schema. The description fully explains what is returned (id, first_name, last_name, email) and when to use it, giving the agent complete information for correct selection and 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?
The tool accepts no parameters, so the schema is trivially 100% covered. The rubric sets a baseline of 4 for zero-parameter tools, and the description adds no parameter-specific information because none is needed.
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 ('List all Splitwise friends') and the resource (friends), and it specifies the returned fields (id, first_name, last_name, email). This distinguishes it from sibling tools like sw_list_groups and sw_get_user.
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 guidance on 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 does not explicitly name alternatives or say when not to use it, so it falls 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?
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?
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.

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