@paigy/mcp 0.9.0 → 0.10.2

package/README.md

@@ -92,11 +92,13 @@ Then pair: `npx -p @paigy/mcp@latest paigy-mcp-onboard`.
 
 ## Tools
 
+- **`pair`** — pair this agent with the user's Paigy account (one-time). No args to start (opens the approval link); pass the returned `device_code` to finish.
+- **`unpair`** — log this agent out of the user's Paigy account; revokes the token server-side and deletes the local one.
 - **`notify_user`** — notify the user (context: title + description chunks; a required `select` answer shape — `one`/`many`/`rank` take `options`, `confirm`/`text` don't; plus `visuals`, `urgency`, and `parentId` for a clarification). Options carry no ids — the backend assigns them by position ("1", "2", …) and answers reference those; each option can carry a sandboxed `html` or `image` preview for visual "pick one" decisions. Returns `{ notificationId, threadId }`. If a reply comes back as `{kind:'clarify', chunks:[...]}`, respond via notify_user with the SAME threadId and an expanded description.
 - **`await_reply`** — wait for the user's reply to a specific notification (pass its notificationId). Scoped: will not return replies meant for other notifications. Returns `reply` / `remind` / `idle`.
-- **`check_replies`** — catch-up sweep: returns replies you haven't consumed yet (now marked seen) plus still-pending notifications.
-- **`poll_answer`** — fetch the answer to a specific notification by notificationId.
+- **`check_replies`** — catch-up sweep: returns replies you haven't consumed yet (now marked seen) plus still-pending notifications, new user-initiated requests, and owed callbacks.
 - **`set_task_state`** — report progress on a request: `in_progress` / `completed` / `needs_input`.
+- **`schedule_callback`** — promise the user a follow-up (`on_done` / `on_blocked` / `scheduled`) so it's not dropped if you go idle.
 
 ## Configuration
 

package/dist/{chunk-L6IEPZCY.js → chunk-5EY3Q5DX.js}

@@ -103,7 +103,16 @@ var ScheduleCallbackSchema = z.object({
 });
 var PendingRepliesSchema = z.object({
   replies: z.array(
-    z.object({ threadId: z.string(), notificationId: z.string(), answer: UserAnswerSchema })
+    z.object({
+      threadId: z.string(),
+      notificationId: z.string(),
+      answer: UserAnswerSchema,
+      /** True if this reply was already claimed on a prior check_replies/await_reply —
+       *  re-surfaced because includeRecent recovered it (e.g. after an unexpected
+       *  restart). You may have already acted on it; check before repeating a
+       *  side-effecting response. */
+      redelivered: z.boolean().optional()
+    })
   ),
   pending: z.array(
     z.object({ threadId: z.string(), notificationId: z.string(), createdAt: z.string() })
@@ -257,6 +266,43 @@ var StatusSchema = z.object({
   /** A phone is registered for push/ring (any push token on the account). */
   phone: z.boolean()
 });
+var EnvelopeRecipientSchema = z.object({
+  keyId: z.string(),
+  epk: z.string(),
+  wnonce: z.string(),
+  wrap: z.string()
+});
+var EnvelopeHeaderSchema = z.object({
+  field: z.enum(["context", "options", "visuals", "answer"]),
+  kind: z.string(),
+  senderRole: z.enum(["agent", "user"]),
+  recipientKeyIds: z.array(z.string()),
+  seq: z.number().int().nonnegative()
+});
+var EnvelopeSchema = z.object({
+  v: z.literal(1),
+  alg: z.literal("x25519-xsalsa20poly1305"),
+  msgId: z.string(),
+  hdr: EnvelopeHeaderSchema,
+  recipients: z.array(EnvelopeRecipientSchema).min(1),
+  nonce: z.string(),
+  ct: z.string()
+});
+var SealedAnswerSchema = z.object({
+  ignored: z.boolean(),
+  envelope: EnvelopeSchema
+});
+var DeviceCredentialSchema = z.object({
+  deviceId: z.string(),
+  kind: z.enum(["phone", "web", "agent"]),
+  x25519Pub: z.string(),
+  ed25519Pub: z.string(),
+  sig: z.string()
+});
+var DeviceRosterSchema = z.object({
+  uikPub: z.string(),
+  devices: z.array(DeviceCredentialSchema)
+});
 var WakeNudgeSchema = z.object({
   kind: z.enum(["reply", "request", "callback"]),
   notificationId: z.string().optional(),
@@ -348,9 +394,10 @@ async function awaitReply(notificationId, opts = {}) {
     await doSleep(intervalMs);
   }
 }
-async function checkReplies() {
+async function checkReplies(includeRecent = false) {
   const token = loadToken();
-  const res = ensureAuthed(await reach(`${BACKEND_URL}/api/pending`, {
+  const qs = includeRecent ? "?includeRecent=true" : "";
+  const res = ensureAuthed(await reach(`${BACKEND_URL}/api/pending${qs}`, {
     headers: { authorization: `Bearer ${token}` }
   }));
   if (!res.ok) throw new Error(`check_replies failed: ${res.status} ${await res.text()}`);
@@ -384,20 +431,11 @@ async function scheduleCallback(req) {
   if (!res.ok) throw new Error(`schedule_callback failed: ${res.status} ${await res.text()}`);
   return await res.json();
 }
-async function pollAnswer(notificationId) {
-  const token = loadToken();
-  const res = ensureAuthed(await reach(`${BACKEND_URL}/api/poll/${notificationId}`, {
-    headers: { authorization: `Bearer ${token}` }
-  }));
-  if (!res.ok) throw new Error(`poll failed: ${res.status} ${await res.text()}`);
-  return await res.json();
-}
 
 export {
   NotifyRequestSchema,
   SetTaskStateSchema,
   ScheduleCallbackSchema,
-  DeliveryModeSchema,
   WAKE_EVENT,
   wakeChannel,
   submitNotification,
@@ -405,6 +443,5 @@ export {
   checkReplies,
   setTaskState,
   registerDelivery,
-  scheduleCallback,
-  pollAnswer
+  scheduleCallback
 };

package/dist/index.js

@@ -1,17 +1,14 @@
 #!/usr/bin/env node
 import {
-  DeliveryModeSchema,
   NotifyRequestSchema,
   ScheduleCallbackSchema,
   SetTaskStateSchema,
   awaitReply,
   checkReplies,
-  pollAnswer,
-  registerDelivery,
   scheduleCallback,
   setTaskState,
   submitNotification
-} from "./chunk-L6IEPZCY.js";
+} from "./chunk-5EY3Q5DX.js";
 import {
   deleteToken,
   openBrowser,
@@ -60,13 +57,14 @@ function json(s) {
 }
 
 // src/index.ts
-var PollAnswerSchema = z.object({
-  notificationId: z.string().describe("The notificationId returned by notify_user.")
-});
 var AwaitReplySchema = z.object({
   notificationId: z.string().describe("The notificationId returned by notify_user \u2014 waits for the user's reply to THIS notification only.")
 });
-var CheckRepliesSchema = z.object({});
+var CheckRepliesSchema = z.object({
+  includeRecent: z.boolean().optional().describe(
+    "Set true only if you just unexpectedly restarted/reconnected and might have already claimed a reply without acting on it (that reply won't show up again otherwise \u2014 claims are one-time). Re-includes replies from the last ~10 min, marked redelivered:true so you can tell they may be duplicates. Leave false/omitted for normal use."
+  )
+});
 var PairSchema = z.object({
   device_code: z.string().optional().describe("Omit to start pairing (returns an approval link to show the user). Pass the device_code from that first call to finish, once the user has approved.")
 });
@@ -74,11 +72,6 @@ var SetTaskStateToolSchema = z.object({
   notificationId: z.string(),
   state: SetTaskStateSchema.shape.state
 });
-var RegisterDeliveryToolSchema = z.object({
-  mode: DeliveryModeSchema.describe(
-    "'self_hosted' = the API pushes the moment work lands (requires `npx -y @paigy/mcp paigy-listen` running); 'poll' = the default, you catch up via check_replies/await_reply."
-  )
-});
 function detectGit() {
   const run = (cmd) => {
     try {
@@ -99,14 +92,14 @@ var server = new Server(
   { name: "paigy", version: "0.0.0" },
   {
     capabilities: { tools: {} },
-    instructions: "On startup, call check_replies once to pick up any replies or pending work you missed while away. To wait for the answer to something you just asked, call await_reply with that notificationId \u2014 it's scoped to that one request, so it never returns replies meant for other requests. Use check_replies again only when re-booting or after waiting a long time on something else. Never end a turn that still needs the user without notify_user + await_reply. When you need a decision or input, MATCH the answer shape to the question \u2014 don't default everything to free text, and don't reflexively make everything yes/no. Pick the best tool for the job: yes/no \u2192 select:'confirm'; approve/deny an action \u2192 select:'confirm' + confirmStyle:'approve'; pick one of several \u2192 options + select:'one'; pick several / a subset \u2192 options + select:'many'; rank or prioritize \u2192 options + select:'rank'. Reserve select:'text' (free-form reply only) for plain updates and answers that genuinely can't be structured (the user can always add free text on top of any shape). If a reply comes back as { kind: 'clarify', chunks: [...] }, the user wants more detail on those chunks \u2014 respond by calling notify_user again with the SAME threadId and an expanded description covering them. When urgency is 'call', remember the title + description are spoken aloud \u2014 write them short and conversational, and name things instead of using IDs (e.g. 'the pull request about the agents page', not 'PR #235'). When the user asks you to follow up later \u2014 when you're done, if you're blocked, or at a set time \u2014 record it with schedule_callback so you don't drop it if you go idle. If you're about to start a genuinely long-running or blocking piece of work \u2014 one where the user would otherwise sit and wait \u2014 mention ONCE, in passing, that you can text or call them when it's done or if you hit a blocker, instead of them needing to babysit the terminal. Don't offer this for quick tasks, and don't repeat the offer if they've already said yes or no earlier in the conversation. Escalate silence, don't just wait on it: if you notified at a lower urgency (inbox/push/banner) for something that's genuinely blocking real progress, call await_reply up to twice (~5 min each, ~10 min total) \u2014 if it's still idle after that AND the item is genuinely blocking, send a fresh notify_user on the SAME threadId at urgency:'call'. Skip this for anything that isn't truly blocking; a normal question can just sit in the inbox."
+    instructions: "On startup, call check_replies once to pick up any replies or pending work you missed while away. To wait for the answer to something you just asked, call await_reply with that notificationId \u2014 it's scoped to that one notification, so it never returns replies meant for other notifications. Use check_replies again only when re-booting or after waiting a long time on something else. Never end a turn that still needs the user without notify_user + await_reply. When you need a decision or input, MATCH the answer shape to the question \u2014 don't default everything to free text, and don't reflexively make everything yes/no. Pick the best tool for the job: yes/no \u2192 select:'confirm'; approve/deny an action \u2192 select:'confirm' + confirmStyle:'approve'; pick one of several \u2192 options + select:'one'; pick several / a subset \u2192 options + select:'many'; rank or prioritize \u2192 options + select:'rank'. Reserve select:'text' (free-form reply only) for plain updates and answers that genuinely can't be structured (the user can always add free text on top of any shape). On a { kind: 'clarify' } reply, see notify_user's own description for how to respond. When urgency is 'call', remember the title + description are spoken aloud \u2014 write them short and conversational, and name things instead of using IDs (e.g. 'the pull request about the agents page', not 'PR #235'). When the user asks you to follow up later \u2014 when you're done, if you're blocked, or at a set time \u2014 record it with schedule_callback so you don't drop it if you go idle. If you're about to start a genuinely long-running or blocking piece of work \u2014 one where the user would otherwise sit and wait \u2014 mention ONCE, in passing, that you can reach them when it's done or if you hit a blocker, instead of them needing to babysit the terminal. Don't offer this for quick tasks, and don't repeat the offer if they've already said yes or no earlier in the conversation. Escalate silence, don't just wait on it: if you notified at a lower urgency (inbox/push/banner) for something that's genuinely blocking real progress, call await_reply up to twice (~5 min each, ~10 min total) \u2014 if it's still idle after that AND the item is genuinely blocking, send a fresh notify_user on the SAME threadId at urgency:'call'. Skip this for anything that isn't truly blocking; a normal question can just sit in the inbox."
   }
 );
 server.setRequestHandler(ListToolsRequestSchema, async () => ({
   tools: [
     {
       name: "pair",
-      description: "Pair this agent with the user's Paigy account (one-time) \u2014 required before notify_user/await_reply work. Two steps: (1) call with NO args to start; it opens the user's browser and returns { verification_uri_complete, user_code, device_code } \u2014 show the user the URL + user_code and ask them to approve. (2) call again passing that device_code to finish; it waits for approval and saves the token. If it returns { status:'pending' }, the user hasn't approved yet \u2014 call again with the same device_code to keep waiting.",
+      description: "Pair this agent with the user's Paigy account (one-time) \u2014 required before notify_user/await_reply work. Two steps: (1) call with NO args to start; it attempts to open the user's browser and returns { verification_uri_complete, user_code, device_code }. That attempt can silently fail in headless/remote environments (no browser to open) \u2014 always show the user verification_uri_complete AND user_code regardless of whether it opened, so they can go there manually and enter the code themselves if needed; ask them to approve. (2) call again passing that device_code to finish; it waits for approval and saves the token. If it returns { status:'pending' }, the user hasn't approved yet \u2014 call again with the same device_code to keep waiting.",
       inputSchema: json(PairSchema)
     },
     {
@@ -116,34 +109,24 @@ server.setRequestHandler(ListToolsRequestSchema, async () => ({
     },
     {
       name: "notify_user",
-      description: "Notify the user via Paigy. Returns { notificationId, threadId } \u2014 pass notificationId to await_reply/poll_answer for the answer, threadId to notify_user to continue the conversation. Provide context.title (a specific, non-empty one-line headline \u2014 this is what the user sees first, and what shows on the ring for a call) and context.description (an array of standalone, non-empty detail chunks the user can selectively ask you to expand). Set `urgency`: 'inbox' (default) drops it silently in their inbox; 'push' is a quiet passive notification (no sound); 'banner' sends a time-sensitive banner/lock-screen push (a 'paige') they tap to open \u2014 for when you need them soon-ish but not enough to ring them; 'call' rings their phone now as a voice call \u2014 only when you genuinely need them in the moment (blocked/waiting, time-sensitive). ON A CALL, your title + description are READ ALOUD by a voice \u2014 write them to be HEARD, not read: keep it short and conversational, front-load the ask, and refer to things BY NAME, not by ID or code (say 'the pull request about the agents page', not 'PR #235'; 'the login-bug ticket', not 'ABC-1234'). Spell out only what's natural to say out loud. MATCH the answer shape to the question \u2014 `select` is required; pick the best tool for the job, not always yes/no. The user can ALWAYS add free text on top of any shape, so structuring loses nothing. Choose `select`: yes/no \u2192 select:'confirm' \u2192 {kind:'confirm', approved:boolean}. Approve/deny an action \u2192 select:'confirm' + confirmStyle:'approve' \u2192 {kind:'confirm', approved:boolean}. Both are answerable right from the banner. Pick one of several \u2192 options + select:'one' \u2192 {kind:'option', optionId}. Pick several / a subset \u2192 options + select:'many' \u2192 {kind:'multi', optionIds:[...]}. Rank or prioritize \u2192 options + select:'rank', user taps in preferred order \u2192 {kind:'ranked', optionIds:[...]}. Options carry no ids \u2014 they're assigned by position ('1', '2', \u2026), and the answer's optionId(s) are those positions. For visual choices give each option a sandboxed `html` or an `image` preview (e.g. layout/UI alternatives); use `visuals` for images that set context for the whole question. select:'text' = free-form reply only (plain updates, or answers that genuinely can't be structured). If a reply comes back as {kind:'clarify', chunks:[...]}, the user wants more detail on those chunks \u2014 respond via notify_user with the SAME threadId and an expanded description. Pass `threadId` from a prior notify_user result or an await_reply reply to continue that conversation thread; omit it to start a new one. To follow up on a call (e.g. the user asked you to 'call me back when it's done'), reuse the threadId from that call's reply so it threads as the same conversation.",
+      description: "Notify the user via Paigy. Returns { notificationId, threadId } \u2014 pass notificationId to await_reply for the answer, threadId to notify_user to continue the conversation. Provide context.title (a specific, non-empty one-line headline \u2014 this is what the user sees first, and what shows on the ring for a call) and context.description (an array of standalone, non-empty detail chunks the user can selectively ask you to expand). Set `urgency`: 'inbox' (default) drops it silently in their inbox; 'push' is a quiet passive notification (no sound); 'banner' sends a time-sensitive banner/lock-screen push (a 'paige') they tap to open \u2014 for when you need them soon-ish but not enough to ring them; 'call' rings their phone now as a voice call \u2014 only when you genuinely need them in the moment (blocked/waiting, time-sensitive). ON A CALL, your title + description are READ ALOUD by a voice \u2014 write them to be HEARD, not read: keep it short and conversational, front-load the ask, and refer to things BY NAME, not by ID or code (say 'the pull request about the agents page', not 'PR #235'; 'the login-bug ticket', not 'ABC-1234'). Spell out only what's natural to say out loud. MATCH the answer shape to the question \u2014 `select` is required; pick the best tool for the job, not always yes/no. The user can ALWAYS add free text on top of any shape, so structuring loses nothing. Choose `select`: yes/no \u2192 select:'confirm' \u2192 {kind:'confirm', approved:boolean}. Approve/deny an action \u2192 select:'confirm' + confirmStyle:'approve' \u2192 {kind:'confirm', approved:boolean}. Both are answerable right from the banner \u2014 no need to open the app. Pick one of several \u2192 options + select:'one' \u2192 {kind:'option', optionId}. Pick several / a subset \u2192 options + select:'many' \u2192 {kind:'multi', optionIds:[...]}. Rank or prioritize \u2192 options + select:'rank', user taps in preferred order \u2192 {kind:'ranked', optionIds:[...]}. One/many/rank/text all need the user to open the app to answer \u2014 only confirm is answerable straight from the banner. Options carry no ids \u2014 they're assigned by position ('1', '2', \u2026), and the answer's optionId(s) are those positions. For visual choices give each option a sandboxed `html` or an `image` preview (e.g. layout/UI alternatives); use `visuals` for images that set context for the whole question. select:'text' = free-form reply only (plain updates, or answers that genuinely can't be structured). If a reply comes back as {kind:'clarify', chunks:[...]}, the user wants more detail on those chunks \u2014 respond via notify_user with the SAME threadId and an expanded description. Pass `threadId` from a prior notify_user result or an await_reply reply to continue that conversation thread; omit it to start a new one. To follow up on a call (e.g. the user asked you to 'call me back when it's done'), reuse the threadId from that call's reply so it threads as the same conversation.",
       inputSchema: json(NotifyRequestSchema)
     },
-    {
-      name: "poll_answer",
-      description: "Fetch the user's answer to a previous notify_user request (pass its notificationId). Returns status pending | answered | ignored, with the answer once present. Errors if the notificationId is unknown or expired.",
-      inputSchema: json(PollAnswerSchema)
-    },
     {
       name: "await_reply",
-      description: "Wait for the user's reply to THE specific notification you sent for the current request (pass the notificationId from notify_user). This is how you wait for your answer in-context. Polls ~5 min; returns { type:'reply', answer } when they respond, { type:'remind', remindInSeconds } on snooze (ScheduleWakeup then await_reply again), or { type:'idle' }. Scoped to that one notification \u2014 it NEVER returns replies meant for other notifications/requests, so concurrent requests don't cross. A CALL answer can come back as {kind:'turns', turns:[{prompt,reply}]} \u2014 the ordered log of that call. Read turns[0].reply as the user's main instruction and any later turns as their follow-up (e.g. the end-of-call 'call me back when it's done / I have a blocking question' reply). If they asked for a callback, re-engage in the SAME thread (notify_user with the reply's threadId) when the task is done or you hit a blocker \u2014 urgency:'call' for a blocker, 'banner'/'push'/'inbox' for done. Paigy has no scheduler; the callback is yours to send (use ScheduleWakeup/cron for timing).",
+      description: "Wait for the user's reply to a specific notification you sent (pass the notificationId from notify_user). This is how you wait for your answer in-context. Polls ~5 min; returns { type:'reply', answer } when they respond, { type:'remind', remindInSeconds } on snooze (ScheduleWakeup then await_reply again), or { type:'idle' }. Scoped to that one notification \u2014 it NEVER returns replies meant for other notifications, so concurrent notify_user calls don't cross. A CALL answer can come back as {kind:'turns', turns:[{prompt,reply}]} \u2014 the ordered log of that call. Read turns[0].reply as the user's main instruction. Usually that's the only turn; if there are more (e.g. an end-of-call 'call me back when it's done / I have a blocking question'), read each one in order as a further follow-up instruction, not a single combined one. If they asked for a callback, re-engage in the SAME thread (notify_user with the reply's threadId) when the task is done or you hit a blocker \u2014 urgency:'call' for a blocker, 'banner'/'push'/'inbox' for done. Paigy has no scheduler; the callback is yours to send (use ScheduleWakeup/cron for timing).",
       inputSchema: json(AwaitReplySchema)
     },
     {
       name: "check_replies",
-      description: "The catch-up router for everything NOT tied to your current request: returns replies the user sent that you haven't seen yet (now marked seen), still-pending notifications you sent, and `requests` \u2014 new requests the user started toward you (each { notificationId, threadId, text }, returned once). Act on each request and reply with notify_user on the SAME threadId. Use it when booting up / starting a session, or when you've been waiting a long time on something else, to discover acks or work you're unaware of. To wait on a request you just sent, use await_reply instead. Also returns owedCallbacks: callbacks now due that you promised \u2014 fulfill each with notify_user on its threadId.",
+      description: "The catch-up sweep for everything you haven't consumed yet: returns answers to notifications you sent that you haven't seen (now marked seen), your still-pending notifications, and `requests` \u2014 new requests the user started toward you (each { notificationId, threadId, text }, returned once). Act on each request and reply with notify_user on the SAME threadId. Use it when booting up / starting a session, or when you've been waiting a long time on something else, to discover acks or work you're unaware of. To wait on an answer to a notify_user call you just made, use await_reply instead. Also returns owedCallbacks: callbacks now due that you promised \u2014 fulfill each with notify_user on its threadId. Pass includeRecent:true only right after an unexpected restart, to recover a reply you may have claimed but not acted on.",
       inputSchema: json(CheckRepliesSchema)
     },
     {
       name: "set_task_state",
-      description: "Report progress on a request you received: in_progress (you started working), completed (done), or needs_input (you need more from the user \u2014 usually paired with a notify_user carrying parentId = this request's id).",
+      description: "Report progress on a user-initiated request you received (from check_replies): in_progress (you started working), completed (done), or needs_input (you need more from the user \u2014 usually paired with a notify_user carrying parentId = the same notificationId you're reporting on).",
       inputSchema: json(SetTaskStateToolSchema)
     },
-    {
-      name: "register_delivery",
-      description: "Choose how Paigy reaches you when a reply or new request lands. 'self_hosted' makes Paigy PUSH it instantly over a realtime channel instead of you polling \u2014 but it only helps if a `paigy listen` daemon is running (npx -y @paigy/mcp paigy-listen), which the user runs once. 'poll' (default) keeps the catch-up model (check_replies / await_reply). Either way no work is ever lost: a missed push is reconciled by your next check_replies sweep.",
-      inputSchema: json(RegisterDeliveryToolSchema)
-    },
     {
       name: "schedule_callback",
       description: "Promise the user a follow-up you'll keep even if you go idle. Use it when they ask you to report back: trigger 'on_done' (when you finish \u2014 fires when you call set_task_state completed), 'on_blocked' (if you hit a blocker \u2014 fires on set_task_state needs_input), or 'scheduled' with dueInSeconds (e.g. 'remind me in 10 min'). Pass the threadId of the conversation and a short note. Fulfill it by calling notify_user on that threadId; check_replies re-lists due callbacks until you do.",
@@ -173,7 +156,7 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
         };
       }
       const start = Date.now();
-      const capMs = 3e4;
+      const capMs = 9e4;
       while (Date.now() - start < capMs) {
         const token = await pollToken(device_code);
         if (token) {
@@ -193,7 +176,7 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
           text: JSON.stringify({
             status: "pending",
             device_code,
-            message: "Still awaiting approval after ~30s. Call pair again with this device_code to keep waiting."
+            message: "Still awaiting approval after ~90s. Call pair again with this device_code to keep waiting."
           })
         }]
       };
@@ -232,19 +215,14 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
       const result = await submitNotification(enriched);
       return { content: [{ type: "text", text: JSON.stringify(result) }] };
     }
-    case "poll_answer": {
-      const { notificationId } = PollAnswerSchema.parse(request.params.arguments);
-      const result = await pollAnswer(notificationId);
-      return { content: [{ type: "text", text: JSON.stringify(result) }] };
-    }
     case "await_reply": {
       const { notificationId } = AwaitReplySchema.parse(request.params.arguments);
       const item = await awaitReply(notificationId);
       return { content: [{ type: "text", text: JSON.stringify(item) }] };
     }
     case "check_replies": {
-      CheckRepliesSchema.parse(request.params.arguments ?? {});
-      const result = await checkReplies();
+      const { includeRecent } = CheckRepliesSchema.parse(request.params.arguments ?? {});
+      const result = await checkReplies(includeRecent);
       return { content: [{ type: "text", text: JSON.stringify(result) }] };
     }
     case "set_task_state": {
@@ -252,11 +230,6 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
       const result = await setTaskState(notificationId, state);
       return { content: [{ type: "text", text: JSON.stringify(result) }] };
     }
-    case "register_delivery": {
-      const { mode } = RegisterDeliveryToolSchema.parse(request.params.arguments);
-      const result = await registerDelivery(mode);
-      return { content: [{ type: "text", text: JSON.stringify(result) }] };
-    }
     case "schedule_callback": {
       const result = await scheduleCallback(ScheduleCallbackSchema.parse(request.params.arguments));
       return { content: [{ type: "text", text: JSON.stringify(result) }] };

package/dist/listen.js

@@ -4,12 +4,14 @@ import {
   checkReplies,
   registerDelivery,
   wakeChannel
-} from "./chunk-L6IEPZCY.js";
+} from "./chunk-5EY3Q5DX.js";
 import "./chunk-GU7C5H6L.js";
 
 // src/listen.ts
 import { createClient } from "@supabase/supabase-js";
 import { spawn } from "child_process";
+import { realpathSync } from "fs";
+import { fileURLToPath } from "url";
 var emit = (obj) => void process.stdout.write(JSON.stringify(obj) + "\n");
 async function sweep(reason) {
   try {
@@ -51,7 +53,16 @@ async function main() {
   process.on("SIGINT", () => void shutdown());
   process.on("SIGTERM", () => void shutdown());
 }
-if (process.argv[1] && import.meta.url.endsWith(process.argv[1].replace(/^file:\/\//, ""))) {
+function isEntry() {
+  const arg = process.argv[1];
+  if (!arg) return false;
+  try {
+    return realpathSync(arg) === fileURLToPath(import.meta.url);
+  } catch {
+    return false;
+  }
+}
+if (isEntry()) {
   main().catch((e) => {
     emit({ type: "fatal", message: e.message });
     process.exit(1);

package/dist/statusline.js

@@ -7,9 +7,10 @@ import {
 } from "./chunk-GU7C5H6L.js";
 
 // src/statusline.ts
-import { mkdirSync, readFileSync, writeFileSync } from "fs";
+import { mkdirSync, readFileSync, realpathSync, writeFileSync } from "fs";
 import { homedir } from "os";
 import { join } from "path";
+import { fileURLToPath } from "url";
 var DIR = join(homedir(), ".paigy");
 var CACHE = join(DIR, "status.json");
 var TTL_MS = 6e4;
@@ -57,9 +58,16 @@ async function main() {
     return cached ? render(cached.status) : "paigy: \u2026";
   }
 }
-if (process.argv[1] && import.meta.url.endsWith(process.argv[1].replace(/^file:\/\//, ""))) {
-  void main().then((line) => console.log(line));
+function isEntry() {
+  const arg = process.argv[1];
+  if (!arg) return false;
+  try {
+    return realpathSync(arg) === fileURLToPath(import.meta.url);
+  } catch {
+    return false;
+  }
 }
+if (isEntry()) void main().then((line) => console.log(line));
 export {
   main,
   render

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@paigy/mcp",
-  "version": "0.9.0",
+  "version": "0.10.2",
   "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",