sw_undelete_group
Restore a soft-deleted Splitwise group by providing its group ID.
Instructions
Restore a soft-deleted Splitwise group.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group ID to restore |
Restore a soft-deleted Splitwise group by providing its group ID.
Restore a soft-deleted Splitwise group.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group ID to restore |
Changes observed during successful MCP inspections.
v3.0.0Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v2.1.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core behavior and the required prior state, but does not mention side effects, permissions, idempotency, or whether the restored group brings back members and expenses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that states the verb, resource, and precondition with no filler. It is appropriately sized for a one-parameter restore operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is mostly sufficient for selection and invocation, but because there are no annotations it omits return/error behavior and the practical meaning of restoration. The interaction with sw_delete_group or how soft-deleted groups are identified is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the only parameter with a clear description ('Group ID to restore'), and schema coverage is 100%. The tool description does not need to add much, but it also does not clarify ID format or how an agent can find soft-deleted group IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('restore') and a precise target ('soft-deleted Splitwise group'), so an agent can tell this from sw_get_group, sw_delete_group, or sw_undelete_expense without extra context. It goes beyond the tool name by clarifying the object must already be soft-deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The precondition 'soft-deleted' implies this tool should be used only for groups that have been deleted but not permanently removed. It does not explicitly mention when not to use it, compare it with sw_delete_group, or point to alternatives such as sw_undelete_expense for expenses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.