omni-notify-mcp 1.2.0 → 1.2.1

package/dist/index.js

@@ -171,7 +171,13 @@ const server = new McpServer({ name: "notify-mcp", version: "1.2.0" }, {
     instructions: "This is the stdio bridge for notify-mcp. It pushes unsolicited user " +
         "messages to the agent via `notifications/claude/channel` when the host " +
         "supports Channels (Claude Code v2.1.80+). Otherwise call `wait_for_inbox` " +
-        "as a long-poll to reliably receive user messages as tool results.",
+        "as a long-poll to reliably receive user messages as tool results.\n\n" +
+        "ALWAYS call `notify` when: (a) a task that took >60s of wall-clock time " +
+        "just finished (success or failure), (b) you have a question or need a " +
+        "decision, (c) something important happened the user needs to know right " +
+        "now. Idle/DND gating is handled server-side — fire notify and let the " +
+        "server decide routing. Err on the side of notifying: a wrong-call gets " +
+        "silently downgraded by idle gating; a missed notify costs the user hours.",
 });
 // Thin proxy: forward a tool call to the HTTP server and return its content
 // block array verbatim. Error shape matches what the SDK expects from tool

package/dist/ui/server.js

@@ -1116,12 +1116,37 @@ channels are in use — just call 'notify' or 'ask' with a generic message.
 
 BEHAVIORAL RULES for every client that connects:
 
-1. Always call 'notify' for milestones, decisions, completions. The SERVER
-   handles all gating (DND, idle, channel routing). You do not need to
-   pre-flight with 'get_idle_seconds' — the server checks it itself and
-   downgrades the delivery automatically. When the user is active, the server
-   will play a local desktop sound+banner so they know something happened
-   (without blasting their phone). Just call 'notify'.
+1. ALWAYS call 'notify' in these three situations — idle or not, DND or not,
+   the server decides routing, you decide whether to fire:
+
+   (a) LONG PROCESSING FINISHED. Any single task that took more than ~60
+       seconds of wall-clock time (long build, test run, backtest, migration,
+       big refactor, multi-step plan) gets a 'notify' the moment it completes
+       — success OR failure. Rule of thumb: if the user could have reasonably
+       walked away to grab coffee while you ran, they need a ping on the way
+       back. Don't try to guess whether they were watching. Just notify.
+
+   (b) YOU HAVE A QUESTION OR NEED A DECISION. Any time you're about to ask
+       the user something — "should I delete these?", "which branch?",
+       "proceed with plan B?" — fire 'notify' (or 'ask' for blocking
+       two-way). Silent questions in the terminal get missed; a notification
+       does not.
+
+   (c) SOMETHING IMPORTANT HAPPENED that the user needs to know about right
+       now. Examples: a test suddenly failed after being green, a destructive
+       operation is about to run, you found a security issue, a deploy
+       succeeded, a production service looks degraded, you hit an
+       unrecoverable error. When in doubt on importance, ERR ON THE SIDE OF
+       NOTIFYING — the server's idle gating will automatically downgrade a
+       mis-judged 'normal' to a silent desktop banner if the user is active,
+       so the cost of over-notifying is near zero. The cost of missing a
+       real event is that the user finds out 4 hours later.
+
+   The SERVER handles all routing (DND, idle threshold, channel selection,
+   priority escalation). You do NOT need to pre-flight with
+   'get_idle_seconds' before these three triggers — fire 'notify' and let
+   the server decide. get_idle_seconds is the HEARTBEAT primitive (rule 6),
+   not a gate on legitimate milestones.
 
 2. Use priority correctly:
    - 'low'    = email only — for low-stakes status (background completion).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "omni-notify-mcp",
-  "version": "1.2.0",
+  "version": "1.2.1",
   "description": "An MCP server that lets AI agents (Claude, Cursor, etc.) reach you on any channel — desktop, Telegram, SMS, email — with two-way ask/reply, real-time inbox push, Do Not Disturb, idle gating, multi-session routing, and a one-page web UI for setup. Zero config code; configure once, agents call notify/ask.",
   "main": "dist/index.js",
   "type": "module",