mailwarden

snooze

Idempotent

Archive a thread now and automatically resurface it at a specified date, time, or preset so deferred messages return when due.

Instructions

Snooze a thread until a date or time: archives it now, resurfaces when it comes due and sweep_snoozed runs. until accepts an explicit date (YYYY-MM-DD), a date+time (YYYY-MM-DD HH:MM or e.g. '2026-06-20 9am'), OR a preset resolved server-side: today, tomorrow, weekend (next Saturday), next week (next Monday), a weekday name (monday–sunday, next occurrence), 'in N days', or 'in N hours'. A preset may carry a trailing time ('tomorrow 9am', 'monday 8:30'). A timed snooze wakes at the next sweep on/after that minute. USE WHEN: deferring a thread to a later date/time instead of leaving it in the inbox. DO NOT USE: for permanent removal (use archive or trash). SIDE EFFECTS: removes INBOX, adds a dated MCP/Snoozed label; reversible via unsnooze.

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>",
      "until": "<until>"
    },
    "name": "snooze"
  }
}

Input Schema

Name	Required	Description	Default
`until`	Yes
`threadId`	Yes

Output Schema

Name	Required	Description	Default
`threadId`	Yes
`snoozedUntil`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.25.0Oct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
Changed2 schema fields changedv0.6.0Aug 7, 2026
- addedInput schema / properties / until / minLength
```
Added value: +1
```
- removedInput schema / properties / until / pattern
```
Removed value: -"^\\d{4}-\\d{2}-\\d{2}$"
```
First observedv0.1.8Jul 24, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only give the safety profile (non-read-only, non-destructive, idempotent), while the description adds the substantive behavior: INBOX removal, addition of a dated MCP/Snoozed label, wake-up semantics relative to sweep_snoozed, and reversibility. The timing caveat ('a timed snooze wakes at the next sweep on/after that minute') is exactly the kind of non-obvious trait annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and side effects are front-loaded, and the USE WHEN / DO NOT USE / SIDE EFFECTS structure makes it scannable. The preset enumeration is long but necessary given 0% schema coverage, though it makes the block dense rather than tight.

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 two-parameter mutation with an output schema present, everything an agent needs is covered: what it does, when to choose it, what it changes, when it takes effect, and how to undo it. Return values are correctly left to the output schema.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden, and it does: `until` formats (YYYY-MM-DD, date+time variants), the full preset vocabulary (today, tomorrow, weekend, next week, weekday names, 'in N days/hours'), and trailing-time composition rules. This is far more than the bare string type in the schema.

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 ('Snooze a thread until a date or time') and immediately explains the mechanism (archives now, resurfaces when due and sweep_snoozed runs). It explicitly distinguishes itself from archive and trash, so an agent can separate it from siblings without opening any schema.

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?

Contains explicit USE WHEN (deferring a thread instead of leaving it in the inbox) and DO NOT USE (permanent removal — use archive or trash) sections naming the alternatives. It also points to unsnooze as the reversal path, leaving nothing to inference.

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