Skip to main content
Glama
3021244161

ipynb-mcp

by 3021244161
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

notebook_run

Execute selected Jupyter notebook cells in resume, replay, or full mode, preserving kernel state and writing fresh outputs; inspect executed cell status to catch failures.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
modeNoExecution mode: 'auto' (default) | 'resume' | 'replay' | 'full'
pathYesNotebook path
cell_selectorNoWhich code cells to run: 'all' (default), '3', '0-4', or a comma list like '0-4,7,9'. This is a string selector — do not pass an array.
create_backupNoDefault true
write_outputsNoWrite fresh outputs back to the .ipynb. Default true
timeout_secondsNoPer-cell timeout in seconds (1..86400; default from server config)
clear_outputs_beforeNoClear target cells' outputs before running. Default true
expected_content_hashNoOptional optimistic-lock hash

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.2
    • removedInput schema / properties / mode / enum
      Removed value: -[
-  "auto",
-  "resume",
-  "replay",
-  "full"
-]
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that 'replay' silently rebuilds state from cell 0, that 'full' does not reset a live kernel or import cache, and warns that 'completed' does not imply all cells succeeded. It omits side effects like backup creation, output write-back, and state destruction from replay, which a mutation tool ideally surfaces.

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?

Front-loaded with the verb and purpose, then mode semantics, then the validation caveat. Dense but every sentence earns its place; the triple-clause mode sentence is tight rather than padded.

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 an 8-param mutation tool with no annotations and no output schema, the description covers execution semantics and even return-value inspection (executed[].status). It leaves the write-back, backup, timeout, and hash-locking behaviors to the schema, which is reasonable but not fully 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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning the schema lacks — the schema only lists mode values, while the description explains what resume/replay/full actually do. Other params remain schema-only.

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?

States a specific verb+resource ('Execute notebook cells') that clearly separates it from notebook_read/notebook_edit. It does not explicitly name the sibling run-family tools (notebook_run_status, notebook_run_cancel) it could be confused with, so it stops short of full sibling differentiation.

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?

Strong mode-level guidance: resume vs replay vs full are each given a condition, and 'For clean validation, restart the kernel before full' is an explicit when-to-use rule. It doesn't route the agent to sibling tools (e.g., status/cancel) for monitoring or aborting a run, so it lacks the alternatives layer of a 5.

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

Deploy Server

Other Tools