@paigy/mcp 0.31.0 → 0.31.1

package/dist/index.js

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 import {
   HandoffSchema
-} from "./chunk-Z5FEQ4GK.js";
+} from "./chunk-PYORUJ7Q.js";
 import {
   PAIGY_TOOL_IDS,
   autoConfigureClients,
@@ -129,7 +129,7 @@ var CONTACT_SCHEMA = {
   },
   required: ["ask"]
 };
-var CONTACT_DESCRIPTION = "Reach the user through Paigy \u2014 tell them something, or ask and get their answer. State what you need in `ask`, say what happens to your work while you wait in `waiting`, and Paigy handles the rest (channel, phrasing, answer format). If the user explicitly asks you to CALL them, send waiting:'hard' and say so in the ask. Returns { notificationId, parentId } \u2014 pass notificationId to await_reply for the answer, parentId to a later contact to continue the conversation. THREADING REPLACES: a threaded follow-up SUPERSEDES your earlier pending items on that thread \u2014 right for updates to one ask, WRONG for a checklist (send independent to-dos un-threaded). A threaded re-send with IDENTICAL content escalates the pending ask in place. If a reply comes back as {kind:'clarify', chunks:[...]}, the user wants more detail \u2014 contact again on the SAME parentId with an expanded ask. ONE ASK, ONE ROW: never restate a still-pending ask's question inside a NEW contact (e.g. weaving it into a briefing) \u2014 the whole answer settles on the new row and the original can never receive it. Keep waiting on the original (a live call reads every pending ask out separately, each answer routes to its own row), and use `needs` for a genuinely multi-part NEW ask.";
+var CONTACT_DESCRIPTION = "Reach the user through Paigy \u2014 tell them something, or ask and get their answer. State what you need in `ask`, say what happens to your work while you wait in `waiting`, and Paigy handles the rest (channel, phrasing, answer format). If the user explicitly asks you to CALL them, send waiting:'hard' and say so in the ask. Returns { notificationId, parentId } \u2014 pass notificationId to await_reply for the answer, parentId to a later contact to continue the conversation. When it rang, the reply also carries { ifMissed: { mode, means } }: what the user's own policy does with a call they don't take (\"Rings again 10 min, 30 min and 2 hr after the missed call, then leaves it in your inbox\"), so a no-answer tells you how long to wait before coming back. THREADING REPLACES: a threaded follow-up SUPERSEDES your earlier pending items on that thread \u2014 right for updates to one ask, WRONG for a checklist (send independent to-dos un-threaded). A threaded re-send with IDENTICAL content escalates the pending ask in place. If a reply comes back as {kind:'clarify', chunks:[...]}, the user wants more detail \u2014 contact again on the SAME parentId with an expanded ask. ONE ASK, ONE ROW: never restate a still-pending ask's question inside a NEW contact (e.g. weaving it into a briefing) \u2014 the whole answer settles on the new row and the original can never receive it. Keep waiting on the original (a live call reads every pending ask out separately, each answer routes to its own row), and use `needs` for a genuinely multi-part NEW ask.";
 var ONBOARD_DESCRIPTION = "Get this agent talking to Paigy \u2014 call it FIRST, before contact/await_reply, and any time you're unsure who you are. One call, and it does whatever the situation needs: NOT SET UP \u2192 hatches an identity instantly if this machine holds a device credential (the user ran the Paigy desktop app or harness), otherwise starts the code ceremony; ALREADY SET UP \u2192 returns your current identity and offers the two things left to decide, renaming it or unpairing; TOKEN NO LONGER VALID \u2192 says so, then re-pairs. Pass { name, voice } to choose who you are when hatching, or to RENAME yourself when already set up (voices: rachel, george, jessica, brian, lily). Safe to call any time: idempotent, and it never writes settings \u2014 the tool-allowlist state it reports is read-only. If it returns a `user_code`, print it to the user immediately and call onboard again with the `device_code`. If it returns `enable_prompt`, ask the user that question and call `enable_tools` on yes.";
 
 // src/pairing.ts
@@ -691,7 +691,9 @@ async function handleTool(request, signal) {
 var beatDown = false;
 async function beat() {
   try {
-    await heartbeat();
+    const token = readToken();
+    if (!token) return;
+    await heartbeat(void 0, { token });
     if (beatDown) console.error("paigy: presence restored \u2014 the live dot is honest again");
     beatDown = false;
   } catch (err) {

package/dist/listen.js

@@ -2,7 +2,7 @@
 import {
   WAKE_EVENT,
   wakeChannel
-} from "./chunk-Z5FEQ4GK.js";
+} from "./chunk-PYORUJ7Q.js";
 import {
   checkReplies,
   registerDelivery

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@paigy/mcp",
-  "version": "0.31.0",
+  "version": "0.31.1",
   "description": "Paigy MCP server — a voice inbox for your AI agents. Lets an agent notify a user and await their reply.",
   "license": "MIT",
   "type": "module",
@@ -36,9 +36,9 @@
     "tsup": "^8.3.5",
     "typescript": "^5.7.2",
     "vitest": "^2.1.8",
+    "@paigy/crypto": "0.0.0",
     "@paigy/schema": "0.0.0",
-    "@paigy/sdk": "0.2.0",
-    "@paigy/crypto": "0.0.0"
+    "@paigy/sdk": "0.2.0"
   },
   "scripts": {
     "build": "tsup",