@paigy/mcp 0.10.2 → 0.10.4

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

@@ -127,6 +127,12 @@ var PendingRepliesSchema = z.object({
    *  fulfill one by calling notify_user on its threadId. */
   owedCallbacks: z.array(
     z.object({ threadId: z.string(), trigger: CallbackTriggerSchema, note: z.string() })
+  ),
+  /** Work (either direction) you reported in_progress a while ago and never reported
+   *  completed — likely left half-done by this session or a prior one that crashed or
+   *  went idle. Report a real state (set_task_state) or continue the work. */
+  stalled: z.array(
+    z.object({ threadId: z.string(), notificationId: z.string(), title: z.string().nullable(), startedAt: z.string() })
   )
 });
 var NotifyResponseSchema = z.object({

package/dist/index.js

@@ -8,7 +8,7 @@ import {
   scheduleCallback,
   setTaskState,
   submitNotification
-} from "./chunk-5EY3Q5DX.js";
+} from "./chunk-UWM2Q4DJ.js";
 import {
   deleteToken,
   openBrowser,
@@ -30,6 +30,7 @@ import {
 } from "@modelcontextprotocol/sdk/types.js";
 import { execSync } from "child_process";
 import { z } from "zod";
+import qrcode from "qrcode-generator";
 
 // src/schema.ts
 import { zodToJsonSchema } from "zod-to-json-schema";
@@ -99,7 +100,7 @@ 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 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.",
+      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, qr }. That open 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. `qr` is a terminal-renderable ASCII QR code of the same link \u2014 a scan-to-pair alternative to opening a browser at all, handy when the user's phone is right there; print it verbatim in a fenced code block. (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)
     },
     {
@@ -119,12 +120,12 @@ server.setRequestHandler(ListToolsRequestSchema, async () => ({
     },
     {
       name: "check_replies",
-      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.",
+      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. Also returns `stalled`: work (either direction) that got reported in_progress via set_task_state a while ago and never reported completed \u2014 likely left half-done by this session or a prior one that crashed or went idle. For each, either continue the work and report a real state, or investigate why it stalled. 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 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).",
+      description: "Report progress on the follow-up work behind ANY notification you own \u2014 a user-initiated request (from check_replies), or your OWN notify_user question once await_reply/check_replies returns its answer and you start acting on it. Pass that notificationId. States: 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). Calling this reliably is what lets a future session's check_replies surface `stalled` work you (or a crashed/idle prior session) left at in_progress without ever reporting completed.",
       inputSchema: json(SetTaskStateToolSchema)
     },
     {
@@ -141,6 +142,9 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
       if (!device_code) {
         const code = await requestCode();
         openBrowser(code.verification_uri_complete);
+        const qr = qrcode(0, "M");
+        qr.addData(code.verification_uri_complete);
+        qr.make();
         return {
           content: [{
             type: "text",
@@ -150,7 +154,8 @@ server.setRequestHandler(CallToolRequestSchema, async (request) => {
               user_code: code.user_code,
               device_code: code.device_code,
               expires_in: code.expires_in,
-              message: "Show the user verification_uri_complete and user_code (their browser should have opened). After they approve, call pair again with this device_code to finish."
+              qr: qr.createASCII(1, 2),
+              message: "Show the user verification_uri_complete and user_code (their browser should have opened). If they'd rather scan than switch to a browser themselves, print `qr` verbatim in a fenced code block (monospace, no extra indentation) \u2014 it's a scannable QR code for the same link. After they approve, call pair again with this device_code to finish."
             })
           }]
         };

package/dist/listen.js

@@ -4,7 +4,7 @@ import {
   checkReplies,
   registerDelivery,
   wakeChannel
-} from "./chunk-5EY3Q5DX.js";
+} from "./chunk-UWM2Q4DJ.js";
 import "./chunk-GU7C5H6L.js";
 
 // src/listen.ts

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@paigy/mcp",
-  "version": "0.10.2",
+  "version": "0.10.4",
   "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",
@@ -25,11 +25,13 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.0.4",
     "@supabase/supabase-js": "^2.47.10",
+    "qrcode-generator": "^2.0.4",
     "zod": "^3.24.1",
     "zod-to-json-schema": "^3.24.1"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",
+    "@types/qrcode-generator": "^1.0.6",
     "tsup": "^8.3.5",
     "typescript": "^5.7.2",
     "vitest": "^2.1.8",