@paigy/mcp 0.40.10 → 0.40.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +22 -10
- package/dist/{chunk-UFOR2QEP.js → chunk-NOZRU5CD.js} +570 -435
- package/dist/{chunk-HCCUK3ZL.js → chunk-R2GTL7N3.js} +500 -469
- package/dist/{chunk-AK5AVPF6.js → chunk-SKLVQ73Q.js} +1 -1
- package/dist/{chunk-QAQET3PZ.js → chunk-SO5NRTXG.js} +56 -5
- package/dist/enable.js +9 -4
- package/dist/index.js +29 -5
- package/dist/listen.js +43 -12
- package/dist/onboard.js +4 -4
- package/dist/slot.js +1 -1
- package/dist/statusline.js +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -117,8 +117,8 @@ Then pair: `PAIGY_AGENT=gemini npx -p @paigy/mcp@latest paigy-mcp-onboard`.
|
|
|
117
117
|
## Tools
|
|
118
118
|
|
|
119
119
|
One catalog, on every transport (2026-09-11): the agent tools are `AGENT_TOOLS` in
|
|
120
|
-
`packages/schema/src/tools.ts` — contact, check_replies,
|
|
121
|
-
|
|
120
|
+
`packages/schema/src/tools.ts` — contact, check_replies, create_goal, claim_goal,
|
|
121
|
+
get_goal, update_goal — and both this server and the hosted MCP
|
|
122
122
|
(`apps/api/src/mcp`) publish that list and dispatch it through the SDK's one `runTool`.
|
|
123
123
|
This server adds only onboard, pair and unpair, the tools that mint and delete the token
|
|
124
124
|
file this machine holds. See the [SDK contract](../../packages/sdk/README.md) for the
|
|
@@ -171,18 +171,17 @@ To launch an agent — any agent, not just Claude — when work arrives, set
|
|
|
171
171
|
| `PAIGY_PARENT_ID` | the thread to continue on (`PAIGY_THREAD_ID` is the same value, for existing scripts) |
|
|
172
172
|
| `PAIGY_DELIVERY_ID` | the Delivery being acted on — `contact({deliveryId})` rereads it |
|
|
173
173
|
| `PAIGY_GOAL_ID` | the Goal it belongs to — `claim_goal` it **first** |
|
|
174
|
-
| `PAIGY_CONTEXT_THREAD_ID` | a past conversation this Goal names — `get_thread` it **first** |
|
|
175
174
|
| `PAIGY_TEXT` | what the person said, in prose |
|
|
176
175
|
|
|
177
176
|
Hand `$PAIGY_WORK` to a harness that can read JSON and decide for itself; use the
|
|
178
177
|
scalars for a plain shell launcher that shouldn't need `jq`. They describe **one**
|
|
179
178
|
item — the oldest open Delivery — because the contract is one thread at a time. An
|
|
180
|
-
absent fact is unset rather than empty, so `${
|
|
181
|
-
|
|
179
|
+
absent fact is unset rather than empty, so `${PAIGY_GOAL_ID:-}` distinguishes "no
|
|
180
|
+
Goal" from "an empty id".
|
|
182
181
|
|
|
183
182
|
```sh
|
|
184
183
|
# Claude Code — hand it everything and let it plan:
|
|
185
|
-
PAIGY_ON_WAKE='claude -p "Handle the Paigy work in $PAIGY_WORK — claim_goal first, and
|
|
184
|
+
PAIGY_ON_WAKE='claude -p "Handle the Paigy work in $PAIGY_WORK — claim_goal first, and read a Goal you do not recognize with get_goal."' \
|
|
186
185
|
npx -y -p @paigy/mcp paigy-listen --install
|
|
187
186
|
|
|
188
187
|
# Codex (or any CLI harness) — the scalars are enough for a one-liner:
|
|
@@ -190,6 +189,22 @@ PAIGY_ON_WAKE='codex exec "Claim Paigy goal $PAIGY_GOAL_ID and continue thread $
|
|
|
190
189
|
npx -y -p @paigy/mcp paigy-listen --install
|
|
191
190
|
```
|
|
192
191
|
|
|
192
|
+
### A session that starts listening (`listen`, #2265)
|
|
193
|
+
|
|
194
|
+
Nothing pushes an answer into a session started in a terminal — it waits for that
|
|
195
|
+
session's next `check_replies`. What can reach a running session mid-turn is a watched
|
|
196
|
+
background task, so a terminal session runs `paigy-listen --brief` as its own watched task
|
|
197
|
+
(one human line per event: `Paigy · wake:reply · 2 waiting · lead <deliveryId> on Goal
|
|
198
|
+
<goalId>: "…"`). The `listen` tool is how a session asked to "start listening" gets there
|
|
199
|
+
in one call: it decides and hands over — `listening` (nothing to do), `unpaired` (call
|
|
200
|
+
`onboard`), or `start` with the exact command (this server's own node and `listen.js`,
|
|
201
|
+
`PAIGY_AGENT` and `PAIGY_SESSION_ID` set to this session's slot and id — a session-bound
|
|
202
|
+
identity is refused from any other) for the agent to run as its background task in the
|
|
203
|
+
same turn. It never subscribes, spawns or writes settings. "Already running" is a fact: the
|
|
204
|
+
daemon marks its pid under `~/.paigy/listen/<slot>.pid` while it runs. A session started by
|
|
205
|
+
the Paigy harness (`paigy-harness host` / `run`) needs none of this — its pump types each
|
|
206
|
+
answer in as it lands, and `listen` says so.
|
|
207
|
+
|
|
193
208
|
`$PAIGY_TEXT` is whatever the user said, expanded inside a shell command — keep it
|
|
194
209
|
quoted, as above. For anything longer than a one-liner, point `PAIGY_ON_WAKE` at a
|
|
195
210
|
script and branch on `$PAIGY_EVENT` there:
|
|
@@ -197,10 +212,7 @@ script and branch on `$PAIGY_EVENT` there:
|
|
|
197
212
|
```sh
|
|
198
213
|
#!/bin/sh
|
|
199
214
|
# ~/.paigy/on-wake.sh — chmod +x, then PAIGY_ON_WAKE=~/.paigy/on-wake.sh
|
|
200
|
-
|
|
201
|
-
[ -n "${PAIGY_CONTEXT_THREAD_ID:-}" ] && seed="It continues thread $PAIGY_CONTEXT_THREAD_ID — get_thread that first."
|
|
202
|
-
|
|
203
|
-
codex exec "Paigy goal $PAIGY_GOAL_ID on thread $PAIGY_THREAD_ID. claim_goal it first. The user said: $PAIGY_TEXT. $seed Reply with contact when done."
|
|
215
|
+
codex exec "Paigy goal $PAIGY_GOAL_ID. claim_goal it first. The user said: $PAIGY_TEXT. Reply with contact when done."
|
|
204
216
|
```
|
|
205
217
|
|
|
206
218
|
## Statusline (Claude Code)
|