ipython-kernel-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| IPYTHON_MCP_CONNECTION | No | Path to the Jupyter connection file for a running IPython kernel. The server connects to this existing kernel; the path is resolved from this environment variable unless overridden by the connect_to_kernel tool. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| connect_to_kernelA | Connect to an existing IPython kernel using its connection file. Args: connection_file: Path to the kernel connection JSON file. If not provided, uses the IPYTHON_MCP_CONNECTION environment variable. Returns: Connection status message. |
| execute_codeA | Execute Python code on the connected IPython kernel. Variables persist between calls. Output (stdout, results, errors) is collected and returned as a single string when execution completes. Args: code: Python code to execute. Returns: Execution output (stdout, expression results, or error messages). |
| kernel_statusA | Check the current kernel connection status. Returns: Status message indicating whether a kernel is connected. |
| interrupt_kernelA | Interrupt the current kernel execution by sending SIGINT. Useful for stopping long-running code or infinite loops. Returns: Interrupt status message. |
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 4 tools
Each tool performs a clearly distinct function: connecting, executing, checking status, and interrupting. There is no meaningful overlap or ambiguity between tool purposes.
Most tools follow a verb-first naming pattern (connect_to_kernel, execute_code, interrupt_kernel), but kernel_status is noun-first and breaks the pattern slightly. Overall the naming remains predictable and readable.
Four tools is a well-scoped count for a focused IPython kernel integration. Each tool fills a necessary role without unnecessary bloat.
The core lifecycle of connect, execute, check status, and interrupt is covered. Missing disconnect or restart operations are minor gaps that agents can work around, but the main workflows are supported.