Mike Kelly has published mikekelly/pi-mcp-events, a Pi extension that feeds external activity into an existing agent session and starts another turn when it is idle. Paired with Figma listen, it can bring design comments and edits back to Pi without another terminal prompt. That removes a familiar review chore: copying what changed in the design into the agent's chat.
Kelly's October 5 verification account describes the full loop with Figma: Pi creates a rectangle, an external controller changes it, and the event wakes Pi to revise it again. The account reports one user prompt and two completed agent turns. We inspected the implementation and ran its unauthenticated checks; the detailed live transcript is not public, and we have not independently repeated that authenticated experiment.
The useful development is nevertheless concrete. Feedback left where people already work can become input to an existing assignment. It need not be copied into a chat, and the software deciding when to wake the agent is available to inspect.
Listening and editing are different jobs
The setup divides the work. Figma listen polls Figma's REST API for comments and design changes. It then sends matching activity through an experimental event stream using the Model Context Protocol, or MCP. Pi MCP Events receives that stream; Figma's separate official remote MCP supplies the tools for reading and editing the canvas.
This is not an instantaneous native notification from Figma. The listener targets a three-second polling interval, subject to pacing and rate limits. For design edits it waits until the selected scope has been quiet for 120 seconds, grouping changes before delivery. That can turn several adjustments into one piece of feedback rather than a turn for every movement.
The companion's delivery code batches incoming events over another half-second and submits a follow-up with Pi's turn-triggering option. An idle session starts working; a busy one receives queued input. The message tells the model to treat comments and names as external data and respond within the user's existing request. That instruction expresses the intended boundary; it is not proof that every model response respects it.
In the reported live test, the external change renamed a rectangle and changed its fill from blue to red. Pi unsubscribed, read the design through the editing service, then renamed the rectangle again and made it green. The author reports checking the final state separately. The event identified changed properties, not the new color values: receiving the notification was a reason to inspect the design, not a substitute for reading it.
The extension interface has reached upstream
This also advances a question from our September 30 report on Pi's replaceable MCP machinery. The separate adapter is acquiring its own extension surface. Kelly's October 5 contribution lets companion packages register additional protocol methods while reusing the adapter's connections and authentication. It is included in upstream v5.1.0, released early October 6 UTC.
The interface gives the companion declared requests and streams, rather than a raw connection it can repurpose. Ordinary tool calls retain their separate route and approval handling. The adapter manages connection ownership and cancellation; the companion supplies event interpretation, recovery and wakeup behavior. Other integrations can build on that division without each launching a second connection manager.
The live test used Kelly's adapter fork 5.1.0 with Events 0.2.0 and Pi 1.0.3. The companion's pinned setup still recommends that fork. The upstream release establishes that the generic interface has landed; it does not establish that the reported Figma workflow was retested with the upstream package.
Our isolated check of the pinned companion passed type checking, compilation and 23 of 27 tests. The extension-delivery and HTTP streaming checks passed, but four routing tests failed in both the normal run and a serialized retry. Missing stream identifiers and activation timeouts leave a question about test scheduling or runtime behavior unresolved. These synthetic checks used no model or Figma account; they do not reproduce the live editing claim.
A local loop is a different offer from a hosted watch
Our October 1 analysis asked whether MCP event subscriptions could travel beyond one host and survive restarts. Pi now provides a concrete second implementation to examine. It does not yet answer those questions with compatibility.
ChatGPT's integration contract uses signed webhooks and asks the server to persist subscriptions. Pi's companion implementation accepts streaming delivery and rejects event offerings limited to webhooks or polling. The same broad event idea can therefore require different delivery machinery for each client.
Pi must also stay running. Its subscriptions and replay positions live in memory. The companion can reconnect after an interrupted stream, with bounded retries and replay where the server supports it; restarting Pi requires subscribing again. That fits an active review session more naturally than a watch expected to remain on duty after the laptop closes.
Figma access is a separate constraint. The project's documented write setup uses a third-party OAuth helper that registers the client name as Codex. Pi is not on Figma's approved-client list. Calling the official editing server does not make this official Pi support, and the reported access path may not remain available.
For builders, the transferable gain is the separation of observation, agent wakeup and authorized action. For someone reviewing the work, it means less message carrying during a live session. The next convincing demonstration would use supported access, publish a reproducible task trace, and carry the same event definition into another client with a restart in between. Can the watch keep its meaning when the client changes or the terminal closes?