Which integrations are available for this server?

Connects to Jupyter Notebook (v6.x) servers, enabling cell manipulation, execution, notebook management, and output retrieval through MCP.

How do I use JupyterMCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JupyterMCP Run all cells in the notebook" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

JupyterMCP

by jjsantos01

Overview Schema Related Servers Score Discussions

Local

JupyterMCP - Jupyter Notebook Model Context Protocol Integration

JupyterMCP connects Jupyter Notebook to Claude AI through the Model Context Protocol (MCP), allowing Claude to directly interact with and control Jupyter Notebooks. This integration enables AI-assisted code execution, data analysis, visualization, and more.

⚠️ Compatibility Warning

This tool is compatible ONLY with Jupyter Notebook version 6.x.

It does NOT work with:

Jupyter Lab
Jupyter Notebook v7.x
VS Code Notebooks
Google Colab
Any other notebook interfaces

Related MCP server: Kaggle-MCP

Features

Two-way communication: Connect Claude AI to Jupyter Notebook through a WebSocket-based server
Cell manipulation: Insert, execute, and manage notebook cells
Notebook management: Save notebooks and retrieve notebook information
Cell execution: Run specific cells or execute all cells in a notebook
Output retrieval: Get output content from executed cells with text limitation options

Components

The system consists of three main components:

WebSocket Server (jupyter_ws_server.py): Sets up a WebSocket server inside Jupyter that bridges communication between notebook and external clients
Client JavaScript (client.js): Runs in the notebook to handle operations (inserting cells, executing code, etc.)
MCP Server (jupyter_mcp_server.py): Implements the Model Context Protocol and connects to the WebSocket server

Installation

Prerequisites

Python 3.12 or newer (probably also work with older versions, but not tested)
uv package manager
Claude AI desktop application

Installing uv

If you're on Mac:

brew install uv

On Windows (PowerShell):

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

For other platforms, see the uv installation guide.

Setup

Clone or download this repository to your computer:

git clone https://github.com/jjsantos01/jupyter-notebook-mcp.git

Create virtual environment with required packages an install jupyter-mcp kernel, so it can be recognized by your jupyter installation, if you had one before.
```
uv run python -m ipykernel install --name jupyter-mcp
```
(optional) Install additional Python packages for your analysis:
```
uv pip install seaborn
```
Configure Claude desktop integration: Go to Claude > Settings > Developer > Edit Config > claude_desktop_config.json to include the following:
```
   {
    "mcpServers": {
        "jupyter": {
            "command": "uv",
            "args": [
                "--directory",
                "/ABSOLUTE/PATH/TO/PARENT/REPO/FOLDER/src",
                "run",
                "jupyter_mcp_server.py"
            ]
        }
    }
}
```
Replace /ABSOLUTE/PATH/TO/ with the actual path to the src folder on your system. For example:
- Windows: "C:\\Users\\MyUser\\GitHub\\jupyter-notebook-mcp\\src\\"
- Mac: /Users/MyUser/GitHub/jupyter-notebook-mcp/src/
If you had previously opened Claude, then File > Exit and open it again.

Usage

Starting the Connection

Start your Jupyter Notebook (version 6.x) server:
```
uv run jupyter nbclassic
```
Create a new Jupyter Notebook and make sure that you choose the jupyter-mcp kernel: kernel -> change kernel -> jupyter-mcp
In a notebook cell, run the following code to initialize the WebSocket server:
```
import sys
sys.path.append('/path/to/jupyter-notebook-mcp/src')  # Add the path to where the scripts are located

from jupyter_ws_server import setup_jupyter_mcp_integration

# Start the WebSocket server inside Jupyter
server, port = setup_jupyter_mcp_integration()
```
Don't forget to replace here '/path/to/jupyter-notebook-mcp/src' with src folder on your system. For example:
- Windows: "C:\\Users\\MyUser\\GitHub\\jupyter-notebook-mcp\\src\\"
- Mac: /Users/MyUser/GitHub/jupyter-notebook-mcp/src/
Launch Claude desktop with MCP enabled.

Using with Claude

Once connected, Claude will have access to the following tools:

ping - Check server connectivity
insert_and_execute_cell - Insert a cell at the specified position and execute it
save_notebook - Save the current Jupyter notebook
get_cells_info - Get information about all cells in the notebook
get_notebook_info - Get information about the current notebook
run_cell - Run a specific cell by its index
run_all_cells - Run all cells in the notebook
get_cell_text_output - Get the output content of a specific cell
get_image_output - Get the images output of a specific cell
edit_cell_content - Edit the content of an existing cell
set_slideshow_type- Set the slide show type for cell

⚠️ DISCLAIMER

This is an experimental project and should be used with caution. This tool runs arbitrary Python code in your computer, which could potentially modify or delete data if not used carefully. Always back up your important projects and data.

Example Prompts

Ask Claude to perform notebook operations:

Python example

You can check the example notebook and the video demo

You have access to a Jupyter Notebook server.

I need to create a presentation about Python's Seaborn library.  
The content is as follows:

- What is Seaborn?
- Long vs. Wide data format
- Advantages of Seaborn over Matplotlib
- Commonly used Seaborn functions
- Live demonstration (comparison of Seaborn vs. Matplotlib)
  - Bar plot
  - Line plot
  - Scatter plot

For each concept, I want the main explanations provided in markdown cells, followed by one or more Python code cells demonstrating its usage. Keep the text concise—the cells shouldn't exceed 10 lines each.

Use appropriate slideshow types for each cell to make the presentation visually appealing.

Check Here the full conversation

Stata example

For this example, you need the Stata Software (v17 or later), which is not open source. If you already have Stata, you need to install the stata-setup package:

uv pip install stata-setup

Then, at the begining of your notebook, you need to additionally include:

import stata_setup
stata_setup.config('your_stata_installation_directory', 'your_stata_edition')

You can check the example notebook and the video demo

This exercise comes from Professor John Robert Warren webpage

You have access to a Jupyter Notebook server. By default it runs Python, but you can run Stata (v18) code in this server using the %%stata magic, for example:

%%stata
display "hello world"

Run the available tools to solve the exercise, execute the code, and interpret the results.

**EXERCISE:**

In this exercise, you will use data from the American Community Survey (ACS). The ACS is a product of the U.S. Census Bureau and involves interviewing millions of Americans each year. For an introduction to the ACS, visit the ACS website (here).

For this exercise, I have created a data file containing two variables collected from respondents of the 2010 ACS who lived in one of two metropolitan areas: Minneapolis/St Paul and Duluth/Superior. The two variables are: (1) People's poverty status and (2) the time it takes people to commute to work.

Use STATA syntax files you already have (from the first assignment or class examples) and modify them to accomplish the following goals.

1. Read the data file (`"./stata_assignment_2.dat"`) for this assignment into STATA.
2. Be sure to declare "zero" as a missing value for `TRANTIME`, the commuting time variable.
3. Create a new dichotomous poverty variable that equals "1" if a person's income-to-poverty-line ratio (`POVRATIO`) is less than 100, and "0" otherwise; see the bottom of the assignment for an example of how to do this in STATA.
4. Separately for Minneapolis/St Paul and Duluth/Superior, produce:
   - a histogram of the commuting time (`TRANTIME`) variable.
   - measures of central tendency and spread for commuting time.
   - a frequency distribution for the poverty status (0 vs 1) variable.
5. Separately for Minneapolis/St Paul and Duluth/Superior, use STATA code to produce:
   - a 95% confidence interval for the mean commuting time.
   - a 95% confidence interval for the proportion of people who are poor. See below for an example of how to do this in STATA.

Use the results from step #4 above to:

6. Separately for Minneapolis/St Paul and Duluth/Superior, manually calculate:
   - a 95% confidence interval for the mean commuting time.
   - a 95% confidence interval for the proportion of people who are poor.
7. Confirm that your answers from steps #5 and #6 match.

Based on the results above, answer this question:

8. How do you interpret the confidence intervals calculated in steps #5 and #6 above?

9. Finally, create a do file (.do) with the all the Stata code and the answers as comments.

---

**DESCRIPTION OF VARIABLES IN "STATA ASSIGNMENT 2.DAT"**

**METAREAD** (Column 4-7)  
Metropolitan Area  
- `2240`: Duluth-Superior, MN/WI  
- `5120`: Minneapolis-St. Paul, MN  

**POVRATIO** (Column 18-20)  
Ratio of person's income to the poverty threshold:  
- `<100`: Below Poverty Line  
- `100`: At Poverty Line  
- `>100`: Above Poverty Line  

**TRANTIME** (Column 21-23)  
Travel time to work  
- `0`: Zero minutes  
- `1`: 1 Minute  
- etc.

Check Here the full conversation

Testing with External Client

You can test the functionality without using Claude Desktop with the included external client:

uv run python src/jupyter_ws_external_client.py

This will provide an interactive menu to test some available functions.

For automated testing of all commands:

uv run python src/jupyter_ws_external_client.py --batch

Troubleshooting

Connection Issues: If you experience connection timeouts, the client includes a reconnection mechanism. You can also try restarting the WebSocket server.
Cell Execution Problems: If cell execution doesn't work, check that the cell content is valid Python/Markdown and that the notebook kernel is running.
WebSocket Port Conflicts: If the default port (8765) is already in use, the server will automatically try to find an available port.

Limitations

Only supports Jupyter Notebook 6.x
Text output from cells is limited to 1500 characters by default
Does not support advanced Jupyter widget interactions
Connection may timeout after periods of inactivity

License

MIT

Other Jupyter MCPs

This project is inspired by similar MCP integrations for Jupyter as:

Available Tools

11 tools

edit_cell_contentA

Edit the content of a specific cell by its index and optionally execute it

Args:
    index: The index of the cell to edit
    content: The new content for the cell
    execute: If True and the cell is code, execute after editing and return output

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes
`content`	Yes
`execute`	No

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries transparency burden. It discloses that execute triggers code execution and returns output, but does not explain side effects like overwriting behavior, state changes, or error handling when cell is not code.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is short, front-loaded with purpose, and structured in a clear Args list. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description partially covers return values (output for execute=true) but lacks details on format, error scenarios, or behavior when cell is not code. Adequate but with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The Args list in the description provides clear semantics for each parameter beyond the schema: index identifies the cell, content is new text, execute conditionally runs code and returns output. This adds meaningful context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Edit' and resource 'cell content', and specifies the action of optionally executing. It distinguishes from siblings like get_cells_info (read-only) and run_cell (execute-only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for editing a cell's content with optional execution, but lacks explicit guidance on when to use alternatives (e.g., run_cell for execution only) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cells_infoB

Get information about all cells in the notebook

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states the action but not whether it's read-only, how it returns data, or any prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, and efficient. However, it could be slightly more descriptive without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks detail about return value or format. Given zero parameters and no output schema, the description provides minimal context. Adequate but could be improved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description does not need to add parameter info, aligning with the baseline score of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it gets information about all cells in the notebook, but does not specify what 'information' includes, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like get_notebook_info or get_cell_text_output. The agent must infer from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cell_text_outputA

Get the text output content of a specific code cell by its index

Args:
    index: The index of the cell to get output from
    max_length: Maximum length of text output to return (default: 1500 characters)

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes
`max_length`	No

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether the tool is read-only, what happens on invalid index, or whether it truncates output. The max_length parameter is mentioned but without explanation of overflow behavior or defaults beyond 1500.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a single clear sentence for purpose followed by parameter explanations. No redundant information, and the most important details are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool without output schema, the description covers the main purpose and parameters. However, it could be enhanced by noting that the cell must have text output (not image) or that the output is a string. Overall, it is mostly complete given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add meaning. It explains that 'index' is the cell index and 'max_length' is the maximum length, including the default. However, it does not specify whether index is zero-based, allowed ranges, or the behavior when max_length is exceeded.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (Get), resource (text output content of a specific code cell), and identifier (by index). It is distinct from sibling tools like get_image_output or get_cells_info which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving text output from a cell, but does not explicitly contrast with alternatives like get_image_output or mention restrictions (e.g., cell must have been executed). The context of sibling tools helps, but the description itself lacks explicit when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_image_outputA

Get image outputs from a specific cell by its index

Args:
    index: The index of the cell to get images from

Returns:
    A list of images from the cell output

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description discloses basic functionality and returns a list of images, but lacks details on side effects, authentication, or specific return format (e.g., base64 vs file paths).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is succinct and well-structured with an Args and Returns section, front-loading the purpose with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately covers purpose, parameter, and return type. It misses details on error conditions or image formats, but is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the single parameter 'index' as 'the index of the cell to get images from', adding meaning beyond the schema's type and title, which is valuable since schema coverage is 0%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Get image outputs' and the resource 'from a specific cell by its index', distinguishing it from siblings like get_cell_text_output which retrieves text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing images from a cell, but provides no explicit guidance on when to use this tool over alternatives, such as when text outputs are needed instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_notebook_infoB

Get information about the current Jupyter notebook

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility. It does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or has side effects. The minimal description fails to provide transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that is front-loaded with the action. While short, it could benefit from more structure (e.g., specifying return value) but remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, the description should hint at what information is returned (e.g., metadata, kernel status). It does not, making it only minimally complete for an agent to effectively use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, so schema coverage is 100% by default. The description adds no parameter-specific value, but with no parameters, this is acceptable. A score of 4 reflects the baseline for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (get) and resource (notebook information), distinguishing it from siblings that focus on cells. However, it lacks specificity on what 'information' includes, leaving the agent uncertain about the output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., get_cells_info for cell-level details). The description does not mention prerequisites, context, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

insert_and_execute_cellA

Insert a cell at the specified position and execute it, and optionally set slideshow type. If code cell, it will be executed. If markdown cell, it will be rendered.

Args:
    cell_type: The type of cell ('code' or 'markdown')
    position: The position to insert the cell at
    content: The content of the cell
    slideshow_type: Optional slideshow type ('slide', 'subslide', 'fragment', 'skip', 'notes')

ParametersJSON Schema

Name	Required	Default
`cell_type`	No	code
`position`	No
`content`	No
`slideshow_type`	No

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must bear full burden. It mentions execution/rendering behavior but fails to disclose side effects (e.g., whether the notebook is modified, permission requirements, error handling on invalid position). This is a significant gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is front-loaded with the main action and then breaks down parameters. It is mostly concise, though the backtick formatting is slightly informal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description covers the main action and parameters but omits return values, error conditions, and the fact that the tool modifies the notebook. It is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description's Args section explains each parameter's meaning and lists acceptable values for slideshow_type. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it inserts a cell at a specified position and executes it, distinguishing code vs markdown execution. This differentiates it from siblings like run_cell (runs existing cell) and edit_cell_content (edits without insert).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (insert+execute) but does not explicitly state when not to use or suggest alternatives. For example, it doesn't mention that set_slideshow_type sibling could be used separately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pingA

Simple ping command to check server connectivity

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It only says 'Simple ping command to check server connectivity' without detailing behavior like response format or latency. For a simple tool, this is minimally adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence that completely describes the tool's purpose with no wasted words. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite simplicity, the description does not mention what the tool returns (e.g., success/failure) or any edge cases. For a tool with no output schema and no annotations, more context would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in the input schema, and schema description coverage is 100%. Baseline for 0 parameters is 4, and the description adds no parameter info as none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'ping' and resource 'server connectivity', and the name itself is standard. It distinguishes well from sibling tools which are all notebook cell operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives mentioned, but the tool name and description imply it's for connectivity testing. With unrelated siblings, the usage is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_all_cellsA

Restart and run all cells in the notebook. You need to wait for user approval

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions restarting (implies state reset) and need for approval, but does not detail side effects like variable loss or execution time.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences, no fluff. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is minimal. It covers core action and a requirement, but misses behavioral nuances like effects on kernel state or timing. Sibling tools provide context but description itself could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the schema covers all aspects. The description adds no parameter info (unnecessary), meeting the baseline of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Restart and run all cells in the notebook.' This distinguishes it from sibling tools like 'run_cell' (single cell) and 'insert_and_execute_cell' (insert and run one cell).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly mentions 'You need to wait for user approval', which provides a clear usage constraint. However, it does not explicitly state when to use or not use this tool versus alternatives, though the purpose implicitly differentiates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_cellC

Run a specific cell by its index

Args:
    index: The index of the cell to run

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must cover behavior. Only states 'run' without disclosing side effects, state changes, error handling, or cell execution environment.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short description with docstring, but the docstring is redundant with schema. Could be more efficient by merging or removing redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing output schema and context on cell state, validation, or error propagation. For a 1-param tool with many siblings, more context on cell execution lifecycle is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0% and description only restates schema ('index: The index of the cell to run'). Adds no extra meaning like valid range, format, or edge cases.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states action ('Run') and resource ('specific cell') with parameter 'index'. Distinguishes from sibling tools like edit_cell_content and run_all_cells.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs. alternatives like run_all_cells or insert_and_execute_cell. No when-not clauses or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_notebookA

Save the current Jupyter notebook

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose side effects (e.g., overwriting, synchronization, blocking). It only says 'save', lacking behavioral context beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with zero waste, effectively conveying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description is adequate. It could mention synchrony or checkpoint behavior but is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so baseline is 4. No additional parameter information is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Save') and the resource ('current Jupyter notebook'), distinguishing it from sibling tools like run_cell or edit_cell_content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, such as whether save is necessary before closing or if auto-save exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_slideshow_typeA

Set the slideshow type for a specific cell by its index

Args:
    index: The index of the cell to modify
    slideshow_type: The slideshow type to set. Valid values are:
                    "slide" - Start a new slide
                    "subslide" - Start a new subslide
                    "fragment" - Fragment (appear on click)
                    "skip" - Skip cell in slideshow
                    "notes" - Speaker notes
                    "-" or null - Remove slideshow type

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes
`slideshow_type`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the operation and valid values, but lacks behavioral context like permissions, side effects, or irreversibility. Without annotations, description carries full burden but still adequately covers the action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Efficient docstring format with clear Args section. No wasted words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple tool with 2 parameters and no output schema, description fully covers purpose, parameters, and valid values. Complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description explains both parameters: index as cell identifier, slideshow_type with all valid values. Adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States 'set the slideshow type for a specific cell by its index' with clear verb and resource. Lists valid slideshow types, distinguishing it from sibling tools that handle different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage from the description, but no explicit when-to-use or alternatives. Does not mention when not to use or how it relates to other slideshow-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: editing, inserting, running cells individually or all at once, retrieving text or image outputs, getting notebook info, saving, and slideshow settings. No two tools overlap significantly.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern (e.g., edit_cell_content, get_cells_info, run_cell). 'ping' is a simple exception but is widely recognized and does not disrupt overall consistency.

Tool Count5/5

With 11 tools, the set is well-scoped for interacting with a Jupyter notebook. It covers navigation, editing, execution, output retrieval, slideshow, and saving without being bloated or sparse.

Completeness4/5

The tool surface covers core notebook operations (edit, insert, run, save, slideshow, output retrieval) but lacks cell deletion, reordering, or kernel management. These are minor gaps for typical workflows.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

platform7n
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2
claude-context-bridge
io.github.PhoenixFeuer32
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Communication Knowledge & Memory Developer Tools
2
Fathom MCP Server
io.github.agencyenterprise
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Communication App Automation Search
216
Threadminder
ai.threadminder
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Knowledge & Memory Project Management
2

Related MCP Servers

QGIS MCP Server
Code Execution Autonomous Agents
jjsantos01
F
license
B
quality
F
maintenance
Connects Claude AI to QGIS through the Model Context Protocol, allowing Claude to directly interact with and control QGIS for tasks like project creation, layer manipulation, and code execution.
Updated a year ago (2025-10-01 01:23 UTC)
15
1,074
Kaggle-MCP
Open Data Research & Data App Automation
54yyyu
A
license
Not graded
quality
D
maintenance
Connects Claude AI to the Kaggle API through the Model Context Protocol, enabling competition, dataset, and kernel operations through the AI interface.
Updated a year ago (2025-06-11 14:28 UTC)
35
MIT
XLMCP
RAG Systems Research & Data
xLydianSoftware
A
license
B
quality
C
maintenance
Enables Claude Code to interact with Jupyter notebooks, perform semantic search over knowledge files, and manage research projects.
Updated 2 months ago (2026-07-06 15:11 UTC)
33
4
MIT
mcp-server-jupyter
Code Execution Data Platforms Developer Tools
ihrpr
A
license
A
quality
C
maintenance
Enables programmatic interaction with Jupyter notebooks, allowing reading, editing, and executing cells via Claude.
Updated 2 years ago (2025-02-01 16:05 UTC)
6
32
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jjsantos01/jupyter-notebook-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server