Skip to main content
Glama
block

Jupyter MCP Server

by block

query_notebook

Query Jupyter notebook information and metadata, including source code, server status, sessions, and cell positions.

Instructions

Query notebook information and metadata on the user-provided server.

This consolidates all read-only operations into a single tool following MCP best practices.

IMPORTANT: Server URL Configuration

This tool requires a server URL to connect to your Jupyter server. You have two options:

Option 1 - Call setup_notebook first (RECOMMENDED): setup_notebook("my_notebook", server_url="http://localhost:9999") query_notebook("my_notebook", "view_source") # Uses stored URL automatically

Option 2 - Pass server_url explicitly every time: query_notebook("my_notebook", "view_source", server_url="http://localhost:9999")

If neither is done, it defaults to http://localhost:8888 which may not be correct.

Args: notebook_path: Path to the notebook file (.ipynb extension will be added if missing), relative to the Jupyter server root. query_type: Type of query to perform. Options: - 'view_source': View source code of notebook (single cell or all cells) - 'check_server': Check if Jupyter server is running and accessible - 'list_sessions': List all notebook sessions on the server - 'get_position_index': Get the index of a code cell execution_count: (For view_source/get_position_index) The execution count to look for. IMPORTANT: This is the number shown in square brackets like [3] in Jupyter UI. Only available for executed code cells. Must be an integer (e.g., 3). COMMON MISTAKE: Don't confuse with position_index! - execution_count=3 finds the cell that was executed 3rd (shows [3] in Jupyter) - position_index=3 finds the 4th cell in the notebook (0-indexed position) position_index: (For view_source) The position index to look for. This is the cell's physical position in the notebook (0-indexed). Examples: first cell = 0, second cell = 1, third cell = 2, etc. Works for all cell types (code, markdown, raw). Must be an integer. cell_id: (For get_position_index) Cell ID like "205658d6-093c-4722-854c-90b149f254ad". This is a unique identifier for each cell, visible in notebook metadata. server_url: Server URL to connect to. If not provided, uses the URL stored by setup_notebook, or falls back to http://localhost:8888

Returns

Union[dict, list, str, int]:
    - view_source: dict (single cell) or list[dict] (all cells) with cell contents/metadata
    - check_server: str status message
    - list_sessions: list of notebook sessions
    - get_position_index: int positional index

Examples

# View all cells in notebook
query_notebook("my_notebook.ipynb", "view_source")

# View cell by execution count (the [3] shown in Jupyter UI)
query_notebook("my_notebook.ipynb", "view_source", execution_count=3)

# View cell by position (first cell=0, second=1, etc)
query_notebook("my_notebook.ipynb", "view_source", position_index=0)

# Get position index of cell with execution count [5]
query_notebook("my_notebook.ipynb", "get_position_index", execution_count=5)

# Get position index by cell ID
query_notebook("my_notebook.ipynb", "get_position_index", cell_id="205658d6-093c-4722-854c-90b149f254ad")

Raises

ValueError: If invalid query_type or missing required parameters
McpError: If there's an error connecting to the Jupyter server

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notebook_pathYes
query_typeYes
execution_countNo
position_indexNo
cell_idNo
server_urlNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Without annotations, the description fully discloses behavioral traits: it's read-only (no mutations), handles connection to Jupyter server with defaults, and enumerates all query types with their effects. It also lists possible exceptions (ValueError, McpError) for error handling 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 well-structured with clear sections (introduction, configuration note, args, returns, examples, raises). However, it is somewhat verbose, especially with the configuration note being repeated in the args section. A slightly more concise version would be ideal, but the organization is good.

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?

Despite no annotations, the description is comprehensive: it covers all 6 parameters, 4 query types with behaviors, return types, default values, error cases, and provides multiple examples. The output schema is effectively described in the Returns section, making the tool fully understandable without external documentation.

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?

With 0% schema description coverage, the description compensates thoroughly. It explains each parameter in detail, including the distinction between execution_count and position_index, the automatic .ipynb extension, and the purpose of server_url. This adds essential meaning beyond the bare 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?

The description clearly states it queries notebook information and metadata, consolidating all read-only operations. It distinguishes itself from sibling tools like execute_notebook_code and modify_notebook_cells, making its purpose unambiguous.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool (read-only queries) versus alternatives (execute or modify). It also offers a recommended workflow with setup_notebook, explains server URL configuration, and warns against common parameter confusion, leaving no doubt about usage context.

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

Install Server

Other Tools

Latest Blog Posts

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/block/mcp-jupyter'

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