| FMRS | 65 / 100 · C | 79 / 100 · B |
|---|
| Reliability | 10 / 20 | 12 / 20 |
|---|
| Security and permissions | 12 / 20 | 18 / 20 |
|---|
| Maintenance | 13 / 20 | 16 / 20 |
|---|
| Documentation | 15 / 20 | 18 / 20 |
|---|
| Setup experience | 15 / 20 | 15 / 20 |
|---|
| Best for | - Users already running a local JupyterLab or JupyterHub who want to attach an AI agent
- Data science and machine learning workflows needing multimodal output (images, plots, text)
- Teams wanting to extend code execution from local to cloud sandboxes such as Datalayer, Kaggle or Google Colab
- Users who want notebook sessions to keep running after the agent disconnects
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Users who do not run any Jupyter Server and do not need Jupyter Notebooks
- Users whose LLM or client cannot handle multimodal image output and who do not want to disable ALLOW_IMG_OUTPUT
- Users who need cloud sandbox variants without network access or the required credentials
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - Access to the Jupyter Server URL (JUPYTER_URL / DOCUMENT_URL / CODE_SANDBOX_URL)
- The Jupyter access token (JUPYTER_TOKEN, or DOCUMENT_TOKEN and CODE_SANDBOX_TOKEN separately)
- Permission to read and write notebook documents and execute code
- Vendor credentials when using cloud sandboxes (e.g. DAYTONA_API_KEY, E2B_API_KEY, CWSANDBOX_API_KEY, CLOUDFLARE_SANDBOX_API_URL / CLOUDFLARE_SANDBOX_API_KEY, Kaggle credentials, Modal credentials)
- Optional OAuth 2.1 scopes with Datalayer hosting: notebooks:read, notebooks:write, code:execute, data:read
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - The AI agent can execute arbitrary code in notebooks, which may lead to data leakage, data corruption or resource abuse
- A leaked token grants the same Jupyter access as the token itself
- Starting JupyterLab with --ip 0.0.0.0 by default widens the network exposure surface
- Cloud sandboxes incur vendor-side costs and may run beyond local resource limits
- A version mismatch between jupyter-mcp-server and code-sandboxes fails on first execution with Unknown sandbox variant: jupyter
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | Claude Desktop, Cursor, Windsurf, VS Code, Cline, Claude Code | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 6 | 0 |
|---|