ipykernel-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| kernel_discoverA | Discover available Jupyter kernel specs and project venvs. Returns a list of dicts with keys: name, display_name, language, source. Use the "name" value as the kernel_name argument to kernel_start. If scan_dir is provided, also checks for a .venv with ipykernel installed at that path and includes it as a "venv:" entry. |
| kernel_startA | Start a kernel by name, as returned by kernel_discover. kernel_name is either a registered Jupyter spec name (e.g. "python3") or a venv reference ("venv:/path/to/project") from kernel_discover. cwd sets the working directory. Defaults to the venv project dir for venv kernels, or the user's home directory for registered specs. Only one kernel can run at a time — call kernel_stop first if one is already running. |
| kernel_statusA | Return the current kernel status. Returns a dict with: running, alive, project_dir, connection_file, python, pending_executions, transport, ip, shell_port, iopub_port. Returns {"running": False} if no kernel is running. |
| kernel_stopA | Stop the running kernel and clean up resources. |
| kernel_restartA | Restart the kernel, clearing all variables, imports, and state. Pending executions are discarded. The kernel process is replaced but the connection is preserved — no need to call kernel_start again. |
| kernel_interruptA | Interrupt the running kernel (send SIGINT). Use this to cancel a long-running execution without losing kernel state. |
| kernel_executeA | Execute code on the running kernel and return structured output. Output is returned as tagged text blocks: [stdout], [stderr], [result] (last expression value), [error] (with traceback), plus image blocks for plots and display calls. If timeout is set and execution exceeds it, returns any output collected so far plus a [pending] block with a msg_id. Pass that msg_id to kernel_get_output to retrieve the rest. Without timeout, blocks until done. |
| kernel_get_outputA | Retrieve output for a pending execution by msg_id. If still running, waits up to timeout seconds (or returns immediately if timeout is omitted). Returns the same tagged blocks as kernel_execute: [stdout], [stderr], [result], [error], images, and [pending] if not yet done. Once complete output is returned, the record is cleaned up — calling again with the same msg_id will return an error. |
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 8 tools
Each tool targets a distinct lifecycle action on the kernel: discover, start, status, restart, interrupt, stop, execute, and get_output. There is no ambiguity between kernel_start/kernel_restart (start launches a new kernel, restart replaces the process while preserving connection), and kernel_execute/kernel_get_output are clearly separated (execute starts, get_output retrieves pending work).
All tools follow a consistent kernel_verb pattern: kernel_discover, kernel_start, kernel_status, kernel_restart, kernel_interrupt, kernel_stop, kernel_execute, kernel_get_output. The naming convention is uniform and predictable across the entire set.
Eight tools is a well-scoped set for a kernel-management MCP server. Each tool covers a distinct and necessary operation for the full kernel lifecycle without redundancy or bloat; the count feels appropriate for the domain.
The tool surface covers the full kernel lifecycle: discovery, start, status, restart, interrupt, stop, execute, and async output retrieval. The only potential gap is code completion/inspection, but for a kernel-execution server the lifecycle coverage is complete with no dead ends.