hive

Overview Schema Source Related Servers Discussions Admin

wake_update

Destructive

Edit a pending wake-up in place to adjust its delay, body, or repeat interval without creating a new ID. Only still-pending wakes can be modified.

Instructions

Edit a pending wake-up you own, in place, without minting a new id. Provide any subset of delay_seconds, body, repeat_every_seconds. delay_seconds is RELATIVE TO NOW, exactly as in wake_set: it moves the next fire time to now + delay_seconds. repeat_every_seconds only changes the interval used for firings AFTER this one; on its own it does not move the next fire time. Only a still-pending wake can be edited; use wake_get to read the result back. delay_seconds and repeat_every_seconds only apply to a delay wake (from wake_set) - an idle wake (from wake_when_idle) fires on watched-agent state and max_wait_seconds instead, so only body can be edited on one.

Input Schema

TableJSON Schema

Name	Required	Description
`body`	No
`wake_id`	Yes
`project_id`	No	Different project override. Use ONLY when the user explicitly asks for another project by name; otherwise stay in the current scope, even when results are empty.
`delay_seconds`	No
`repeat_every_seconds`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`due_at`	Yes
`updated`	Yes
`wake_id`	Yes
`hive_notice`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.2Sep 26, 2026
- addedOutput schema / properties / hive_notice
```
Added value: +{
+  "type": "string"
+}
```
First observedv1.0.0Sep 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false, readOnlyHint=false) by disclosing subtle runtime semantics: delay_seconds is relative to NOW, repeat_every_seconds only affects firings after the current one and does not move the next fire time by itself, and idle wakes accept only body. These are non-obvious mutation effects an agent could otherwise get wrong.

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, then the caveats, with no filler sentences. It is information-dense but runs long, and the repeat/delay interplay takes two passes to parse fully.

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 5-param mutation tool with an output schema (no need to describe returns), the description covers the pending-only constraint, field applicability per wake type, and the relative timing semantics. Nothing material is missing for correct invocation.

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 only 20%, so the description must compensate, and it does for delay_seconds, repeat_every_seconds and body with precise relative-vs-absolute semantics. wake_id and the project_id override are left to the schema (project_id has its own description), a minor remaining gap.

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+resource (edit a pending wake-up) and the key differentiator from wake_set: in-place edit without minting a new id. An agent can separate it from the create/cancel siblings immediately.

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?

Explicitly scopes usage: 'Only a still-pending wake can be edited', and spells out which fields apply to a delay wake vs an idle wake from wake_when_idle. It even names wake_get as the read-back alternative, so alternatives are covered.

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