Follow-up to #490 (the MCP capstone in v0.0.200).
Why
The single biggest UX gap surfaced by the v0.0.200 live-fire smoke. Today, agents watching for new resources have to poll `list_resources` / `read_resource`. For chat-style interactions (forum messages, bot conversations, real-time docs) that's the wrong shape — latency-sensitive and wasteful.
JSS already has the primitive: `/.notifications` WebSocket with the `solid-0.1` protocol. The work is wiring it through MCP, not building a new notification system.
What
A new MCP tool:
```
subscribe — Subscribe to change events on a resource or container subtree.
Returns an SSE-streamed sequence of MCP notifications as resources
change. Subscription is WAC-gated (Read on each emitted resource).
```
Wire path: MCP server, on `tools/call` for `subscribe`, switches the HTTP response into SSE mode (Streamable HTTP transport allows this — return `text/event-stream` instead of `application/json`). Subscribes server-side to the existing notification pipe, filters events by the agent's WAC visibility, emits each as an MCP notification.
```
event: notification
data: {"jsonrpc":"2.0","method":"notifications/resource_changed","params":{"path":"/forum/channels/general/abc.jsonld","kind":"created"}}
```
Scope
- Streamable HTTP SSE response path in `src/mcp/index.js`
- New `subscribe` tool handler that bridges `src/notifications/` to the SSE stream
- Per-event WAC filtering (don't leak resources the agent can't see)
- Cleanup on client disconnect
- Test: subscribe, write a resource via another path, observe the event
- Doc update in `docs/mcp.md`
Estimated ~150-250 lines including tests.
Acceptance
Related
Follow-up to #490 (the MCP capstone in v0.0.200).
Why
The single biggest UX gap surfaced by the v0.0.200 live-fire smoke. Today, agents watching for new resources have to poll `list_resources` / `read_resource`. For chat-style interactions (forum messages, bot conversations, real-time docs) that's the wrong shape — latency-sensitive and wasteful.
JSS already has the primitive: `/.notifications` WebSocket with the `solid-0.1` protocol. The work is wiring it through MCP, not building a new notification system.
What
A new MCP tool:
```
subscribe — Subscribe to change events on a resource or container subtree.
Returns an SSE-streamed sequence of MCP notifications as resources
change. Subscription is WAC-gated (Read on each emitted resource).
```
Wire path: MCP server, on `tools/call` for `subscribe`, switches the HTTP response into SSE mode (Streamable HTTP transport allows this — return `text/event-stream` instead of `application/json`). Subscribes server-side to the existing notification pipe, filters events by the agent's WAC visibility, emits each as an MCP notification.
```
event: notification
data: {"jsonrpc":"2.0","method":"notifications/resource_changed","params":{"path":"/forum/channels/general/abc.jsonld","kind":"created"}}
```
Scope
Estimated ~150-250 lines including tests.
Acceptance
Related