ipynb-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| IPYNB_ROOT | No | Root directory fence. The server fences all paths to this directory. Defaults to the process working directory. | |
| IPYNB_IMAGES | No | Image block policy (auto: images only on full-output reads and runs). Default is auto. | auto |
| IPYNB_PYTHON | No | Explicit interpreter (failure is final). Default is auto. | auto |
| IPYNB_LOG_LEVEL | No | stderr log level. Default is info. | info |
| IPYNB_READ_ONLY | No | Only notebook_read and kernel status allowed. Default is false. | false |
| IPYNB_BACKUP_KEEP | No | Rolling backups per notebook. Default is 10. | 10 |
| IPYNB_ARTIFACT_DIR | No | Where image artifacts are written. Default is platform cache. | |
| IPYNB_PREVIEW_LINES | No | Source preview lines. Default is 12. | 12 |
| IPYNB_MAX_IMAGE_BYTES | No | Max bytes per image. Default is 20971520. | 20971520 |
| IPYNB_INLINE_TEXT_CHARS | No | Text output truncation threshold. Default is 20000. | 20000 |
| IPYNB_ALLOW_OUTSIDE_ROOT | No | Allow paths outside the root. Default is false. | false |
| IPYNB_KERNEL_IDLE_SECONDS | No | Idle kernel reclamation. Default is 3600. | 3600 |
| IPYNB_MAX_IMAGES_PER_CALL | No | Image blocks per tool call. Default is 20. | 20 |
| IPYNB_EXEC_TIMEOUT_SECONDS | No | Per-cell timeout. Default is 300. | 300 |
| IPYNB_BACKGROUND_THRESHOLD_SECONDS | No | Runs whose estimated upper bound (timeout_seconds × target cells) exceeds 10× this go background. Default is 30. | 30 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| notebook_readA | Read a Jupyter notebook: cell index, type, source and existing outputs. Set include_outputs='full' to get a cell's outputs including images. |
| notebook_editB | Edit notebook cells. Every source change requires a compare-and-swap anchor (expected_source_hash or expected_text); a mismatch fails the whole request without writing. |
| notebook_runA | Execute notebook cells. mode='resume' runs only target cells in the live kernel; 'replay' silently rebuilds state from cell 0 first; 'full' runs all code cells without resetting a live kernel or its import cache. For clean validation, restart the kernel before full. Inspect executed[].status for cell failures; completed does not mean all cells succeeded. |
| notebook_run_statusA | Poll a background notebook run. include_outputs='none' returns cell status without outputs or images; 'full' (default) retrieves outputs. Check executed[].status: completed means orchestration ended, not that every cell succeeded. |
| notebook_run_cancelB | Cancel a background notebook run started by notebook_run. |
| notebook_kernelC | Inspect or manage the kernels held for notebooks: status, start, shutdown, restart. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools target clearly distinct operations (read, edit, kernel management, run, run status, run cancel). The only mild overlap is the run family, where notebook_run could plausibly be assumed to return status, but the descriptions explicitly clarify that status is polled separately via notebook_run_status.
All tools share a consistent notebook_ prefix with a mostly verb_noun structure (notebook_read, notebook_edit, notebook_run_status, notebook_run_cancel). notebook_kernel deviates slightly by using a noun rather than a verb, but the overall pattern is predictable and readable.
Six tools is well-scoped for notebook lifecycle operations. Each tool covers a distinct concern (read, edit, kernel, run, status, cancel) with no redundancy and no trivially thin surface.
The surface covers the core lifecycle: reading, editing, executing, monitoring, cancelling runs, and managing kernels. Minor gaps exist around notebook creation/deletion and cell-level structural operations, but agents can work around these via editing.