jupyter-rmcp
A self-hosted MCP server providing Claude with an interactive Jupyter environment, including real kernels, persistent notebooks, and optional GPU offload to Google Colab.
README
jupyter-rmcp
A self-hosted MCP server that gives Claude — including the mobile app — an
interactive Jupyter environment: real kernels, notebooks that persist as
.ipynb files you can open yourself, and optional GPU offload to Google
Colab. You run it; it runs your notebooks.
It exists because "Claude writes code" and "Claude runs code and iterates on the output" are different things. Every execution lands in a notebook on your own machine, which a human can watch and edit in JupyterLab at the same time.
- Kaggle on a laptop:
COLAB_ONLY=1makes every kernel a Colab VM under your own Google account — nothing executes locally. See docs/GUIDE.md. - Kaggle from your phone: the same mode fits a free-tier GCE
e2-micro(~475 MB of 1 GB used), published to the Claude app through a Cloudflare tunnel — docs/deploy/gce-cloudflare.md, with the account prerequisites in 日本語. - Reference: DESIGN.md (architecture, session management), docs/AUTH.md (exposing it safely) and docs/IAP-OAUTH.md (the runbook for reaching it from the Claude mobile app), docs/SECURITY.md (threat model), docs/COLAB.md (GPU offload), docs/adr/ (why each choice was made).
What runs
| Service | Role | Exposure |
|---|---|---|
jupyter |
Headless Jupyter Server (kernels + nbs) | internal network + loopback Lab |
mcp |
FastMCP Streamable-HTTP server (/mcp) |
127.0.0.1:7130 |
Both bind loopback only. Raw Jupyter — arbitrary code execution with a token — is never the thing you expose; the MCP server is the only surface intended to go anywhere, and only behind auth (docs/AUTH.md).
Quickstart
git clone <this-repo> && cd jupyter-rmcp
bash scripts/install.sh # generates .env + tokens, builds, starts, health-checks
python scripts/smoke_test.py # exercises the live /mcp endpoint end to end
install.sh is idempotent. Manual equivalent: cp .env.example .env, fill in
JUPYTER_TOKEN and MCP_BEARER, then docker compose up -d --build.
Notebooks live in ./data/notebooks (bind-mounted, survive rebuilds) and are
served to a human at http://127.0.0.1:7131 (JupyterLab, token from .env).
Connect Claude
Claude Code, on the same machine:
claude mcp add --transport http jupyter-rmcp http://127.0.0.1:7130/mcp \
--header "Authorization: Bearer $(grep '^MCP_BEARER=' .env | cut -d= -f2)"
The Claude app (including mobile) needs a public HTTPS URL, so it takes a
reverse proxy or tunnel in front of port 7130 — plus an authenticating layer,
because that URL executes code. docs/AUTH.md covers the options
and the one real gotcha: an OAuth-based proxy sets its own Authorization
header, which collides with MCP_BEARER and returns 401. Pick one, not both.
docs/IAP-OAUTH.md is the step-by-step setup, worked through
on Cloudflare Zero Trust.
Colab-only mode
Set COLAB_ONLY=1 in .env and the server refuses to execute code on the local
backend entirely: start_kernel defaults to backend="colab", and a local
kernel request is rejected. The local Jupyter still stores and serves every
notebook — editing, listing and workspace files keep working — it just never
runs user code.
This is the mode to use on a work laptop, or anywhere "what exactly can this thing run on my machine?" needs a short answer. It requires working Colab credentials; the server refuses to start without them rather than failing one call at a time. Details in docs/GUIDE.md and ADR 0014.
How you use it
One unified interface for both backends: start_kernel(backend=…, gpu=…, notebook_path=…, if_exists=…) → work in the bound notebook → stop_kernel.
backend defaults to local (fast, free) or to colab in colab-only mode;
backend="colab" provisions a GPU/CPU Colab VM on demand (official
google-colab-cli, ADC auth, no browser tab). Notebooks always live on the
server regardless of where the compute is.
- Notebooks are editable documents.
start_kernel()with no name → a freshuntitled-N.ipynb; pass an existing name to continue (if_exists:open/new/error). Edit by cell id, not index:list_cells(path)for ids + summaries, thenpatch_cell(path, old, new, cell_id=…)for cheap unique-substring edits, oredit_cell/insert_cells/move_cell/delete_cell. Passexpected_rev(fromnotebook_rev) so a human's concurrent Lab edit is never clobbered. Run:execute_codeappends and runs ad-hoc code;execute_cell(kernel_id, cell_id=…)re-runs an existing cell in place. - Workspace files share one work root with the notebooks (persistent, visible
to kernels and JupyterLab). Sub-folders auto-create when you write to a
sub-path. Bring data in with
upload_file(path, base64),fetch_to_workspace(url, path), or JupyterLab's Upload button. To use a workspace file on a Colab kernel,upload_to_colab(kernel_id, path)copies it to the VM's/content;download_from_colabbrings a result back. - Kernel state persists across executions, and across MCP restarts: the kernel registry is on disk, so a rebuild does not lose track of live kernels.
- Long jobs:
execute_code(..., background=True)returns ajob_idimmediately; pollget_jobfor live stdout/stderr. Prefer that over growingtimeoutfor training runs and big downloads. - Kaggle: set
KAGGLE_API_TOKENin.env(kaggle.com/settings/api → "Generate New Token"). It stays server-side. Local kernels have it in their env; on a Colab kernel callsetup_kaggle(kernel_id)once — it injects the token into the VM without it ever appearing in execution history. Same idea for HuggingFace viasetup_hf. - Housekeeping:
execute_codeenforces a per-call timeout (EXEC_TIMEOUT_SEC); on timeout the kernel is interrupted and astatus: "timeout"result returned. Idle kernels are reaped afterKERNEL_IDLE_TIMEOUT_SEC(pin_kernelto exempt), at mostMAX_KERNELSat once, and nothing outlivesKERNEL_MAX_AGE_SEC.
MCP tools
Kernels and execution: start_kernel, execute_code, get_job, execute_cell,
stop_kernel, restart_kernel, interrupt_kernel, pin_kernel, list_kernels,
list_variables, list_backends, colab_log, setup_kaggle, setup_hf.
Notebook editing (id-addressed, no execution — design from
nbedit-mcp): notebook_rev, list_cells,
read_cells, insert_cell/insert_cells, patch_cell, edit_cell,
delete_cell, move_cell, create_notebook, list_notebooks.
Workspace files: list_files, create_folder, upload_file,
fetch_to_workspace, upload_to_colab, download_from_colab.
Operations
docker compose ps
docker compose logs -f mcp
docker compose restart mcp
docker compose down # stop everything
Extend the kernel's Python libs by editing jupyter/requirements.txt, then
docker compose up -d --build jupyter.
Tests: pytest -q and ruff check . (unit, no network) plus
python scripts/smoke_test.py (end-to-end against a running stack). CI runs the
first two on every push.
License
MIT — see LICENSE. Bundles the official google-colab-cli
(Apache-2.0) for the Colab backend.
推荐服务器
Baidu Map
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。
Neon MCP Server
用于与 Neon 管理 API 和数据库交互的 MCP 服务器
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。