mailwarden

untrash

Idempotent

Restore a Gmail thread from Trash by removing the TRASH label while preserving user labels; note that INBOX is not re-added, so add INBOX via modify_labels to return it to the inbox.

Instructions

Restore a thread from Trash. SIDE EFFECTS: removes the TRASH label; user labels are preserved, but INBOX is NOT re-added — use modify_labels (add INBOX) to return it to the inbox.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "threadId": "<threadId>"
    },
    "name": "untrash"
  }
}

Input Schema

Name	Required	Description	Default
`threadId`	Yes

Output Schema

Name	Required	Description	Default
`ok`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.25.0Oct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedv0.1.8Jul 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the exact side effects: TRASH label removed, user labels preserved, and INBOX deliberately NOT re-added. That last non-obvious detail is precisely the kind of behavior an agent would otherwise get wrong, and it complements the idempotentHint/destructiveHint declarations rather than repeating them.

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, zero waste, with the primary action front-loaded and the caveat flagged by an explicit 'SIDE EFFECTS:' marker.

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 single-parameter mutation tool with an output schema available, the description covers the action, the state transition, label side effects, and the corrective follow-up. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema alone gives no meaning for 'threadId'. The description implies the target is a thread but adds nothing about the ID format or where to obtain it, so compensation is only partial.

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 and resource ('Restore a thread from Trash'), which cleanly inverts the sibling 'trash' and is distinguishable from 'unsnooze'/'sweep_snoozed' by naming Trash as the source state. An agent can select it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the follow-up case to a named alternative: 'use modify_labels (add INBOX) to return it to the inbox.' It gives clear context for the primary use, though it does not state when NOT to use it (e.g., thread not in Trash).

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