Muninn (munn.is)

muninn_task_snooze

Snooze a task: hide it from reminders (session boot and per-call) until a given time. This is a statement about ONE task, not the whole reminder list. Pass EITHER until (an exact ISO 8601 instant) OR durationMinutes (snooze from now for N minutes) — not both. Hard rule: a snoozed task still reappears immediately once it reaches or passes its due date (urgency >= 1), even if snoozed_until hasn't arrived yet. Snoozing something that's already overdue has no visible effect for that reason. Pass until as '' (empty string) to clear an existing snooze.

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": {
      "taskId": "<taskId>"
    },
    "name": "muninn_task_snooze"
  }
}

Input Schema

Name	Required	Description
`until`	No	ISO 8601 datetime to snooze until. Pass '' to clear an existing snooze. Mutually exclusive with durationMinutes.
`taskId`	Yes	The task's memory ID (full UUID or unique 8-char prefix).
`durationMinutes`	No	Snooze starting now, for this many minutes. Mutually exclusive with until.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only tell the agent this is non-read-only, non-idempotent and non-destructive. The description adds the behavioral traits an agent actually needs: the hard rule that a snoozed task reappears at/after its due date regardless of snoozed_until, and the consequently no-op nature of snoozing an already-overdue task. That is exactly the kind of consequence disclosure the annotations cannot carry.

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?

Front-loaded with the core action and effect, then the two mutually exclusive input modes, then the exception rule, then the clear operation. Every sentence carries information, though the mutual-exclusivity statement and the empty-string clearing duplicate the schema text and could be trimmed.

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 3-param mutation tool with full schema coverage, no output schema and annotations covering only safety hints, the description supplies everything else: effect, scoping, input mode exclusivity, the due-date override rule, and the clear path. Nothing needed to invoke it correctly 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?

Schema description coverage is already 100% and the schema itself states the mutual exclusivity and the empty-string clear behavior. The description reinforces those semantics and adds the 'from now' framing for durationMinutes and the instant framing for until, but adds little genuinely new parameter information beyond 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?

The description opens with a specific verb+resource ('Snooze a task') and immediately defines the effect ('hide it from reminders (session boot and per-call) until a given time'). It also disambiguates scope explicitly: 'This is a statement about ONE task, not the whole reminder list,' which lets an agent separate this tool from sibling task operations without inspecting 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 Guidelines4/5

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

It gives a clear conditional rule for the two input modes ('Pass EITHER until ... OR durationMinutes — not both') and a recovery path ('Pass until as "" to clear an existing snooze'). It does not name a sibling alternative (e.g., muninn_task_update for non-snooze changes), so the when-to-use guidance is strong but not fully comparative.

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

All Muninn (munn.is) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?