@paigy/mcp 0.40.25 → 0.40.27
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 +28 -18
- package/dist/{chunk-EJYXBEWN.js → chunk-4C6SDQ7A.js} +887 -661
- package/dist/{chunk-UAVXYNLV.js → chunk-A5FYZK6P.js} +18 -36
- package/dist/{chunk-2ROD77AW.js → chunk-UQDA7X3W.js} +3 -3
- package/dist/{chunk-GHSB2VP6.js → chunk-X3GTDW5G.js} +728 -539
- package/dist/{dist-NMHU2UNG.js → dist-N6ZJUJV7.js} +5 -7
- package/dist/enable.js +5 -5
- package/dist/index.js +57 -54
- package/dist/listen.js +8 -7
- package/dist/onboard.js +6 -6
- package/dist/slot.js +1 -1
- package/dist/stalled.js +2 -2
- package/dist/statusline.js +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -84,7 +84,7 @@ args = ["-y", "@paigy/mcp@latest"]
|
|
|
84
84
|
env = { PAIGY_AGENT = "codex" }
|
|
85
85
|
```
|
|
86
86
|
|
|
87
|
-
Then pair: `PAIGY_AGENT=codex npx -p @paigy/mcp@latest paigy-mcp-onboard` (or have the agent call the `
|
|
87
|
+
Then pair: `PAIGY_AGENT=codex npx -p @paigy/mcp@latest paigy-mcp-onboard` (or have the agent call the `configure` tool — it pairs under its own name automatically).
|
|
88
88
|
|
|
89
89
|
### Gemini CLI
|
|
90
90
|
|
|
@@ -117,18 +117,28 @@ 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` —
|
|
121
|
-
|
|
120
|
+
`packages/schema/src/tools.ts` — contact, manage_goals, get_goal, search, check_activity,
|
|
121
|
+
send_feedback — 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
|
-
This server adds only
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
123
|
+
This server adds only `configure`, the one identity tool, which pairs, reports who you are,
|
|
124
|
+
renames and logs this agent out (`logOut: true`) over the token file this machine holds, and listen.
|
|
125
|
+
`onboard` is now `configure`; `pair` and `unpair` are folded into it (2026-10-07). See the [SDK contract](../../packages/sdk/README.md) for the
|
|
126
|
+
contact shape. Sending returns immediately unless it asks to `wait`: `wait: true` holds one
|
|
127
|
+
cancellable ~45-second window here for a response to what was sent (the hosted transport
|
|
128
|
+
returns after one read), and `contact({})` holds one for anything addressed to you; after an
|
|
129
|
+
`expired` window, wait again without sending again. Every Goal a contact names must already
|
|
130
|
+
exist (create it with manage_goals); a question with `workItBlocks` asks for a call; a
|
|
131
|
+
question, an update or an answer is at most 250 characters with its context in `units`; and
|
|
132
|
+
`withdrawQuestionIds` takes back a question of yours. `update_goal` is gone (2026-10-07): progress
|
|
133
|
+
is a contact update (one the person does not need yet is kept as the Goal's progress), a review is
|
|
134
|
+
acknowledged with `ackEventIds`, and a Goal is postponed with manage_goals `defer` (you are woken
|
|
135
|
+
when its time comes). Durable Entries and accepted answers can
|
|
128
136
|
repeat on reads; contact with nothing to send receives what is addressed to you (a request the
|
|
129
137
|
user started toward you, an answer relayed to something you asked, a handoff, a question you owe) without
|
|
130
|
-
consuming any of it until you acknowledge it (`ackEventIds`), and
|
|
131
|
-
|
|
138
|
+
consuming any of it until you acknowledge it (`ackEventIds`), and get_goal reads a Goal.
|
|
139
|
+
`claim_goal` is gone (2026-10-07): you are on a Goal from your first write to it (a contact
|
|
140
|
+
naming it, or a manage_goals change), never from a read, so there is nothing to claim or join;
|
|
141
|
+
`who_is_working` is now `check_activity`. manage_goals creates, edits, assigns, organizes and closes work, a change at a
|
|
132
142
|
time. Bookkeeping (`operationId`, the manage request id, the revision an edit was read at) is
|
|
133
143
|
minted here, never asked of the model. Retired
|
|
134
144
|
reply-lease/ACK/work/callback tools and hidden notification aliases are rejected.
|
|
@@ -158,10 +168,10 @@ with `paigy-listen --install` (launchd on macOS, systemd user unit on Linux;
|
|
|
158
168
|
|
|
159
169
|
The read is `receive` (behind `contact({})`) — the open Deliveries addressed to this agent — and it
|
|
160
170
|
**consumes nothing**: no lease, no acknowledgement, and the same read twice returns the
|
|
161
|
-
same list. So the daemon hands the launcher what it found and stops there;
|
|
162
|
-
|
|
163
|
-
token with the agent it launches
|
|
164
|
-
|
|
171
|
+
same list. So the daemon hands the launcher what it found and stops there; it never
|
|
172
|
+
writes, because an agent is on a Goal from its first write and the daemon shares this
|
|
173
|
+
machine's token with the agent it launches: a write here would put that agent on work it
|
|
174
|
+
never started.
|
|
165
175
|
|
|
166
176
|
To launch an agent — any agent, not just Claude — when work arrives, set
|
|
167
177
|
`PAIGY_ON_WAKE` to a command before `--install`:
|
|
@@ -171,8 +181,8 @@ To launch an agent — any agent, not just Claude — when work arrives, set
|
|
|
171
181
|
| `PAIGY_WORK` | everything the wake found, as JSON (`deliveries`, `goal`) |
|
|
172
182
|
| `PAIGY_EVENT` | the wake that caused this run — `boot`, `wake:reply`, `wake:request`… |
|
|
173
183
|
| `PAIGY_PARENT_ID` | the thread to continue on (`PAIGY_THREAD_ID` is the same value, for existing scripts) |
|
|
174
|
-
| `PAIGY_DELIVERY_ID` | the Delivery being acted on
|
|
175
|
-
| `PAIGY_GOAL_ID` | the Goal it belongs to — `
|
|
184
|
+
| `PAIGY_DELIVERY_ID` | the Delivery being acted on (`get_goal` on `PAIGY_GOAL_ID` reads its conversation) |
|
|
185
|
+
| `PAIGY_GOAL_ID` | the Goal it belongs to — read it with `get_goal` **first** |
|
|
176
186
|
| `PAIGY_TEXT` | what the person said, in prose |
|
|
177
187
|
|
|
178
188
|
Hand `$PAIGY_WORK` to a harness that can read JSON and decide for itself; use the
|
|
@@ -183,7 +193,7 @@ Goal" from "an empty id".
|
|
|
183
193
|
|
|
184
194
|
```sh
|
|
185
195
|
# Claude Code — hand it everything and let it plan:
|
|
186
|
-
PAIGY_ON_WAKE='claude -p "Handle the Paigy work in $PAIGY_WORK —
|
|
196
|
+
PAIGY_ON_WAKE='claude -p "Handle the Paigy work in $PAIGY_WORK — read each Goal it names with get_goal first."' \
|
|
187
197
|
npx -y -p @paigy/mcp paigy-listen --install
|
|
188
198
|
|
|
189
199
|
# Codex terminal session: no custom script and no new conversation.
|
|
@@ -227,7 +237,7 @@ script and branch on `$PAIGY_EVENT` there:
|
|
|
227
237
|
```sh
|
|
228
238
|
#!/bin/sh
|
|
229
239
|
# ~/.paigy/on-wake.sh — chmod +x, then PAIGY_ON_WAKE=~/.paigy/on-wake.sh
|
|
230
|
-
codex exec "Paigy goal $PAIGY_GOAL_ID.
|
|
240
|
+
codex exec "Paigy goal $PAIGY_GOAL_ID. Read it with get_goal first. The user said: $PAIGY_TEXT. Reply with contact when done."
|
|
231
241
|
```
|
|
232
242
|
|
|
233
243
|
## Stalled work (turn-end hook — Claude Code, Codex, Gemini CLI, Antigravity)
|