Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_delete_group

DestructiveIdempotent

Delete a Splitwise group and all its expenses for every member. Confirm the group ID first; deletion is destructive and can be undone.

Instructions

Delete a group and all its expenses — for every member, not just you. 🔒 destructive write.

Calls POST /delete_group/{id}. Splitwise destroys the group's associated records: every expense in it disappears for all members. Refused with Error: … writes are disabled unless SPLITWISE_ALLOW_WRITES=1. Undo: splitwise_undelete_group with the same id restores the group and its expenses.

When to Use:

  • Only when the user explicitly asked to delete this group. Confirm the id first with splitwise_get_group, and run splitwise_get_expenses with group_id so the user knows how many expenses will go with it.

When NOT to Use:

  • To leave a group or drop one member (use splitwise_remove_user_from_group).

  • To delete a single expense (use splitwise_delete_expense).

  • With a group NAME — resolve it to an id first (use splitwise_resolve_group).

Returns: A confirmation with the success value Splitwise returned and how to undo it — or, when the body does not say success: true, a note to verify before reporting it as deleted.

Examples:

  • params = {"group_id": 12345}

Error Handling: A refusal that comes back as HTTP 200 with success: false is reported as Error: Splitwise rejected the request ...; 403 → not a member; 404 → wrong id or already deleted.

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint and readOnlyHint=false, but the description adds substantial context beyond them: exactly what gets destroyed (every member's expenses), a write-permission gate (SPLITWISE_ALLOW_WRITES=1), a specific undo path (splitwise_undelete_group), and error semantics including the tricky HTTP 200 + success:false case, 403, and 404.

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?

Front-loaded with the destructive scope, then organized under clear headers (When to Use, When NOT to Use, Returns, Examples, Error Handling). Every section earns its place; nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool, the description covers blast radius, permission gating, undo, error mapping, and parameter prerequisites. An output schema exists, so the Returns section is slightly redundant but harmless, and nothing an agent needs to invoke this safely 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?

Only one parameter, and the schema already describes group_id. The description still adds value by giving a concrete example ({"group_id": 12345}) and warning not to pass a group name, directing the agent to splitwise_resolve_group first.

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?

States a specific verb (delete) and resource (group), plus the blast radius ('all its expenses — for every member, not just you'), which immediately separates it from splitwise_remove_user_from_group and splitwise_delete_expense. The endpoint POST /delete_group/{id} is named explicitly.

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?

Has dedicated 'When to Use' and 'When NOT to Use' sections that name the exact alternatives: splitwise_remove_user_from_group for leaving, splitwise_delete_expense for single expenses, splitwise_resolve_group for name resolution. Prerequisites (confirm id with splitwise_get_group, preview with splitwise_get_expenses) are called out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.