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.

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.

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.

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.

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.

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.