Jupyter MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose. For example, append_execute_code_cell versus execute_cell differ in that one creates a new cell before executing, while execute_cell runs an existing one. execute_temporary_code is separate for temporary code. All other tools operate on different aspects (connect, list, read, write, delete, etc.), leaving no ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, such as connect_notebook, list_cell, overwrite_cell, restart_notebook. The compound verb in append_execute_code_cell is still systematic and matches the pattern.
Tool Count5/5
With 12 tools, the set is well-scoped for a Jupyter notebook interaction server. Each tool serves a distinct operation (connect, list, read, write, execute, etc.) without unnecessary duplication or excessive granularity.
Completeness4/5
The tools cover core workflows: connecting, listing, reading, executing, inserting, deleting, overwriting cells, and restarting kernels. Minor gaps exist, such as no explicit save tool or ability to create a new notebook, but these are non-critical for typical agent interactions.
Average 3.7/5 across 12 of 12 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It mentions timeout and output but fails to disclose behavior on timeout (e.g., error handling), whether execution is blocking, or any side effects on notebook state.
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?
Two concise sentences with clear front-loading. No verbose or redundant content; every word earns its place.
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?
Despite simple tool, missing details on return format, error behavior, and prerequisites. No output schema exists, so description should compensate but does not.
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 is 67%; description adds no extra explanation for 'notebook_name' and 'cell_index' beyond what schema provides. The timeout parameter is only noted as 'seconds' in schema, and description does not enrich that.
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?
Description clearly states action (execute) and resource (specific cell) with timeout and output return. However, it does not differentiate from sibling tools like 'append_execute_code_cell' or 'execute_temporary_code', which have similar purposes.
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 explicit guidance on when to use this tool versus alternatives. The description implies use for executing a cell and obtaining output, but lacks when-not or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partly compensates by disclosing the diff return format, but lacks details on error scenarios, side effects, or the tool's destructive nature.
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?
Two sentences, front-loaded with the core action; concise and to the point, though the second sentence could be integrated for even tighter structure.
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?
The description covers the basic action and return format, but omits prerequisites (cell must exist), error handling, and does not leverage the output schema for further completeness.
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?
The description mentions notebook_name and cell_index in passing but adds no semantic detail beyond the input schema; schema coverage is low (33%), and the description does not compensate adequately.
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 tool overwrites cell content and returns a diff, but does not explicitly distinguish from sibling tools like insert_cell or delete_cell, leaving some ambiguity for selection.
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., insert_cell, execute_cell) is provided; the description only states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses the ordering constraint but omits details like permissions, error handling, or idempotence.
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?
Two sentences with no fluff. Purpose stated first, then additional constraint. Highly 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?
Output schema exists, but description does not explain insertion behavior (e.g., index shifting) or return value. Adequate but not comprehensive for a mutation tool.
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 is low (25%) and description adds no parameter details beyond the schema. The ordering constraint is not parameter-specific.
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 'Insert a cell at the specified index' with a specific verb and resource. While it does not explicitly differentiate from siblings, the action is unambiguous.
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?
Provides explicit guidance when inserting many cells (ascending order). However, lacks when-to-use vs alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions return fields but does not disclose side effects (likely none), prerequisites (e.g., notebook must exist), or whether operation is idempotent. Lacks details on behavior beyond outputs.
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?
Two sentences, front-loaded with purpose, no unnecessary words. Efficiently communicates key information.
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 read tool with no output schema and no annotations, description adequately states what is returned. Could mention error conditions (invalid cell_index, missing notebook) but overall sufficient for typical use.
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 has 67% description coverage. Description adds 'source code, execution count and output' which relates to return_output parameter but does not elaborate on notebook_name or cell_index beyond schema. Baseline score appropriate as description adds minimal extra meaning.
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 tool reads a specific cell and returns source code, execution count, and output. It differentiates from sibling tools like execute_cell or delete_cell by focusing on non-modifying read operation.
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. With 11 sibling tools, explicit context about when to choose read_cell over list_cell or execute_cell would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It mentions clearing packages and variables, but omits potential side effects like unsaved data loss, impact on running executions, or authentication requirements. The presence of an output schema is not leveraged.
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, clear sentence that gets straight to the point with no extraneous words. Front-loaded with the primary action.
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 low parameter count and presence of output schema, the description is adequate but lacks details on prerequisites (e.g., notebook must be connected), return value, and when to use. Leaves some gaps for an agent.
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?
With 0% schema description coverage, the description should compensate. It only says 'specified Notebook' without adding format, example, or context for the single required parameter 'notebook_name'. No value 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?
The description clearly states the action: 'Restart the kernel' and the resource: 'a specified Notebook', and specifies what it does: 'clear all imported packages and variables'. It effectively distinguishes from sibling tools like connect_notebook or execute_cell.
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 clearing state but does not explicitly state when to use this tool versus alternatives (e.g., execute_temporary_code for isolated code, or read_notebook for inspection). No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It correctly indicates the tool performs deletion (a mutation) and provides a crucial order constraint for bulk deletions. However, it lacks details about error handling (e.g., when cell_index is invalid), reversibility, or index shifting after deletion.
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 extremely concise, consisting of two sentences with no redundant information. It front-loads the primary action and adds a critical usage rule in the second sentence.
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 absence of annotations, the description covers the main action and a key usage rule. However, it omits details like prerequisites (notebook must exist, cell must exist), return value (output schema exists but not described), and error behavior. For a simple deletion tool, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only cell_index has a description). The description adds no additional meaning for parameters; it does not clarify notebook_name or further explain cell_index beyond what the schema provides. The mention of 'descending order' relates to usage, not parameter semantics.
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 'Delete a specific cell,' which is a specific verb+resource combination. It also distinguishes itself from sibling tools like list_cell, read_cell, and insert_cell by focusing solely on deletion.
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 provides an explicit guideline: 'When deleting many cells, MUST delete them in descending order of their index.' This is helpful for correct usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., overwrite_cell), but the purpose itself implies deletion is the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of behavioral disclosure. It states the action and return fields but does not mention side effects, required permissions, or performance traits such as caching or real-time data retrieval.
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 two sentences long, front-loading the action and output. Every word adds value, with no redundancy or unnecessary detail.
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, output schema exists), the description covers the essential purpose and return values. It lacks details on whether the list is real-time or cached, but this is a minor gap for a basic list operation.
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?
There are zero parameters in the input schema, so no parameter documentation is needed. The description correctly avoids any parameter-related information, achieving a baseline of 4 for no-parameter tools.
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 tool lists all currently connected notebooks and specifies the returned fields (name, Jupyter URL, Path). This distinguishes it from sibling tools like 'connect_notebook' or 'read_notebook'.
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 obtaining the list of connected notebooks but provides no explicit guidance on when to use versus alternatives like 'connect_notebook' or 'read_notebook'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses that code is temporary (not saved) and returns output. The prohibitions imply that side effects like variable assignments do not persist, but this could be more explicit. Overall, the behavior is well communicated despite minor ambiguity.
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 a clear opening sentence, a list of use cases, and a separate 'DO NOT USE' section. It is fairly concise, though slightly verbose with bullet lists. Front-loads the key behavior.
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 annotations, no output schema, and 0% parameter coverage, the description provides adequate purpose and usage guidance. However, it lacks parameter details and does not describe the output format beyond 'return the output'. It sufficiently differentiates from siblings but misses some contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any parameter-level information beyond field names. It does not explain what 'notebook_name' refers to or what format 'cell_content' expects. The description fails to compensate for the lack of 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 'Execute a temporary code block (not saved to the Notebook)' with verb 'execute' and resource 'temporary code block'. It explicitly differentiates from siblings like 'execute_cell' which saves to the notebook, making the 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 when-to-use cases (Jupyter magic, debugging, intermediate values, temporary stats) and when-not-to-use cases (imports affecting notebook, long-running code). This guides the agent effectively on appropriate use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It states the tool connects to a notebook and kernel but does not disclose behavioral details such as whether it establishes a session, overwrites previous connections, requires authentication (beyond token in schema), or what happens on failure. With no annotations, a score of 3 is appropriate as the description provides basic purpose but lacks deeper behavioral context.
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 extremely concise with two sentences. The first sentence states the action, and the second emphasizes its importance as a prerequisite. No extraneous words or repetition. Every sentence earns its place.
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 has 5 parameters, an output schema, and 11 sibling tools, the description adequately covers the core purpose and usage sequence. However, it could be more complete by explaining the lifecycle of connections (e.g., can only one notebook be connected at a time?) and the semantics of the three modes (connect/create/reconnect) beyond what is in the schema. The output schema exists, so return values need not be described. Score 4 because it is mostly complete but misses some behavioral context.
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?
The input schema has 100% description coverage, so each parameter is already clearly documented. The description adds no additional semantic information beyond what the schema provides. The baseline of 3 is appropriate as the description does not need to repeat schema information.
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 tool connects to a notebook and kernel. It also distinguishes itself from siblings by explicitly labeling this as the 'FIRST STEP' before any subsequent operations, which are all listed as sibling tools (e.g., execute_cell, delete_cell). This provides clear 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?
The description explicitly states this is the first step before any subsequent operations, providing clear usage context. However, it does not specify when NOT to use this tool or what alternatives exist (though siblings are all after-connection steps). The input schema details mode options (connect/create/reconnect) but the description could be more explicit about when each mode is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool reads source content without output (implying no side effects), and describes the return format. It does not mention prerequisites like the notebook needing to be connected, which is partially addressed by the phrase 'connected Notebook'.
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 consists of two short sentences: one stating the purpose and output, and one giving the usage condition. It is front-loaded and concisely provides essential information with no unnecessary text.
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?
An output schema exists, so return values are covered. However, the description omits the prerequisite that the notebook must be connected via a sibling tool (e.g., connect_notebook). For a tool with pagination parameters, it does not explain how limit and start_index interact, though these are documented in the schema. The description is adequate but not fully comprehensive.
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 67% (limit and start_index have descriptions, notebook_name only has title). The tool description does not add extra meaning to parameters beyond the schema. Given coverage above 50%, baseline score of 3 is appropriate.
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 'Read the source content (without output) of a connected Notebook' and specifies the returned content, including Index, Cell Type, Execution Count, and Full Source Content. This verb+resource combination effectively distinguishes it from the sibling 'read_cell' which reads a single 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?
The phrase 'ONLY used when the user explicitly instructs to read the full content of the Notebook' provides a clear condition for use. It does not explicitly mention when not to use it or alternatives, but the conditional statement is sufficient context for an agent to select the tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that a new cell is added, immediately executed, and the output returned. It does not cover error conditions or asynchronous behavior, but the core behavior is clear.
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?
Three concise sentences, front-loaded with purpose. Every sentence adds value: action, recommendation, return value. No wasted 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?
Given moderate complexity and no output schema, the description covers main behavior and return value. It lacks mention of prerequisites (e.g., notebook must exist) but that may be inferred from context. Parameter documentation is weak, but not critically incomplete.
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 description coverage is only 33% (timeout described as 'seconds'). Description adds no extra meaning to parameters; 'cell_content' and 'notebook_name' rely solely on their names, which are somewhat self-explanatory but lack detail on format or constraints.
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 it adds a new code cell to the end and immediately executes it. It uses specific verbs ('Add', 'execute') and resource ('code cell'), and distinguishes from siblings like 'insert_cell' and 'execute_cell'.
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?
Explicitly recommends using this tool instead of combining 'insert_cell' and 'execute_cell' for adding a code cell at the end of a notebook. This provides clear when-to-use guidance and compares to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses the tool returns specific fields and is used for listing, which reasonably implies a read-only operation. No contradiction or missing safety context for a listing tool.
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 with two sentences, front-loading the purpose and then detailing use cases. Every sentence adds value without redundancy.
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 the tool has an output schema (not shown but mentioned), the description covers the purpose, return fields, and use cases. Parameters are adequately addressed, and the simplicity of the operation means minimal extra context is needed. It is complete for a listing tool.
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 67%, with only limit and start_index having descriptions; notebook_name lacks description. The tool description adds general context but does not elaborate on parameter meanings or usage beyond the schema, so it does not significantly compensate for the missing schema coverage.
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 tool lists basic information of cells and specifies the return fields (Index, Type, Execution Count, First Line). It distinguishes itself from siblings like read_cell and delete_cell by focusing on overview and indexing.
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 provides context for when to use the tool: to overview structure or locate cell indices for operations like delete or insert. It implies use for navigation but does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jupyter-mcp-server MCP server](https://glama.ai/mcp/servers/ChengJiale150/jupyter-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ChengJiale150/jupyter-mcp-server)

Score Badge

Copy to your README.md:

[![jupyter-mcp-server MCP server](https://glama.ai/mcp/servers/ChengJiale150/jupyter-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/ChengJiale150/jupyter-mcp-server)

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

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