view_agent, create_agent, or replace_graph through the connector, the chat client renders a read-only version of the studio canvas directly in the conversation. Same renderers, same React Flow viewport, same per-type node UIs you see in the Pleyor studio — just locked down and embedded.
What’s in the canvas
- All 47 node-type renderers — image previews, text bodies, video players, brand cards, sticky notes — identical to the editor
- Live run status overlay — when you trigger a run from chat, the canvas paints node-lifecycle badges (queued / running / completed / failed) in real time
- “Open in Studio” link in the top-right — jump to the full editor for any agent shown in chat
- Zoom, pan, fit-to-view controls in the bottom bar
- Fullscreen toggle — expands the canvas to fill the chat slot when the host supports it
What’s NOT interactive
The canvas is read-only by design. You can pan, zoom, and look — you can’t drag nodes, change config, connect edges, or upload assets from the embed. All of that lives in the studio. The canvas is for understanding, not editing. If you ask the assistant to change the graph (“add a brand context node”, “swap the model”), it doesn’t manipulate the canvas — it callsreplace_graph with a new spec, and the canvas re-renders showing the updated state.
Dark mode + theme
The canvas honours your chat client’s theme. When Claude is in dark mode, the canvas paints dark. CSS tokens (--color-background-primary, etc.) flow from the host and apply to the embedded UI automatically.
How it actually works
For curious readers: the MCP server exposes a single UI resource atui://pleyor/workflow-canvas. The three canvas-bearing tools (view_agent, create_agent, replace_graph) link to it via _meta.ui.resourceUri. The chat client’s MCP-Apps sandbox loads a small HTML shim that pulls a self-contained JavaScript bundle (canvas-bundle.js) from the same origin as the Pleyor web app. The bundle mounts the same ReadOnlyCanvas component the public share page uses, wired to a bridge that receives the tool result over postMessage and pushes per-node lifecycle updates as the run progresses.
The bundle is rebuilt automatically on every web deploy, so what you see in chat always matches the studio.
Limitations
- Inline cap of 500px tall — per the MCP-Apps spec for inline cards. Use the fullscreen toggle for complex graphs.
- No nested iframes — Claude’s current MCP-Apps sandbox CSP doesn’t permit nested iframes, which is why we ship a bundled script rather than embed
/embed/canvasdirectly. - Mobile inline only — the chat client may render us inline on mobile without fullscreen support; that’s a client capability, not ours.
See also
Tools
Which tools render the canvas and how to call them.
Run lifecycle
Understand what each node-status badge means.