JupyterLite WebMCP drops an agent into a live notebook and lets it edit cells, run code
and review changes in real time The problem: the notebook lives in the browser, not on disk. Data scientists work inside a browser tab, and almost nothing that matters in their notebook exists on the filesystem. The cell you just typed but haven't saved. The eleven characters you highlighted with the mouse because they look wrong. The kernel holding the DataFrame in memory. The graph that appeared only because you ran cells in a particular order. To get AI help today you have two bad trades: copy-paste into a chat window, where the model sees a dead snapshot, returns text, and you retype it; or wire a server-side MCP integration, which reads .ipynb bytes from disk — meaning it reads a file that doesn't match what you see on screen — and requires a Jupyter server, permissions, and infrastructure. JupyterLite has no server to talk to in the first place.
Why WebMCP is the only option here. The state that matters exists only inside the browser tab. There is no backend holding it, so a conventional MCP server has nothing to connect to. WebMCP here isn't the convenient option; it's the only option. The tool was built by Allison Coleman and Juan Mendoza, and it ships with a live demo and an open-source repository.
Twenty-two tools that operate on the tab's local state. Every one of the 22 listed tools works on local-tab state: the live NotebookPanel model, which includes edits that have never been saved to disk; the human's current cell, cursor, and exact text selection; the shared Pyodide/WebAssembly kernel used by both human and agent; the IndexedDB-backed contents manager; and threaded review conversations stored in the notebook's own metadata. None of this is proxied or replicated to an external service.
User experience: the notebook becomes the interface. Every existing AI-notebook workflow pastes a second surface over the first: a chat panel, a separate window, a copied cell you retype manually. WebMCP lets the agent act inside the tab the human is already looking at, so the notebook itself becomes the interface instead of a chat transcript that describes it. The focused cell gets a subtle ring; an inline status tag tracks state — Reading, Applying, Running, Done, or Failed with an inline error; a diff button opens the exact before/after difference; and every output the agent produces is timestamped in place. The human never has to ask "what did you just do?" — the document answers that live.
Bidirectional collaboration without shadow copies. Pointing is bidirectional: highlight text with the mouse and say "fix only what I highlighted," and the agent reads the exact substring. One kernel, one document: the agent runs cells on the kernel already loaded with your data, with no shadow copy anywhere. The human always wins conflicts: every mutating tool requires an origin hash from a prior read, and stale writes are rejected with an inline error, never silently overwritten. The notebook remains the ledger: the agent cannot run arbitrary code, only cells that already exist and are visible. The owner decides per cell and per notebook what the agent may touch — write, read, or hidden entirely. The page does not inject its own permission requests; the permission experience stays in the WebMCP client.
Review mode: changes wait for approval before they apply. Flip the agent panel from Direct to Propose and jupyter_update_cell stops applying in place: the change is staged as a reviewable inline diff under the target cell, with Accept and Deny buttons, and the tool call does not resolve until you decide. Accept applies the edit through the same code path Direct uses, so there is still only one place where a cell's source is ever written. Deny returns the reason you typed, encoded as a regular result — PROPOSAL_DENIED — not an error, so the agent's next turn knows why, not just that it was told no.