Jupyter MCP Server

Server Quality Checklist

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

Latest release: v1.0.7
Disambiguation4/5
Most tools have clearly distinct purposes (kernel management, code execution, cell manipulation). However, execute_cell and execute_code overlap in that both execute code; descriptions help distinguish but agents may still misselect. Some tools like list_files and list_notebooks are separate but related.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_kernels, execute_cell, insert_cell). The naming is predictable and intuitive, with no mixing of conventions.
Tool Count5/5
With 15 tools, the server covers core notebook and kernel operations without being bloated. The number is appropriate for the domain, providing necessary functionality without excess.
Completeness3/5
The tool set covers many essential operations (connecting, listing files, executing code, managing cells), but lacks tools for creating new notebooks or listing all notebooks on the server. Users must rely on list_files to find notebooks, which is less direct.
Average 3.9/5 across 15 of 15 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 60 of 64 community issues answered or closed in the last 6 months
- 101 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under BSD 3-Clause.
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?
Annotations already indicate destructive hint, but the description adds minimal behavioral context beyond stating it returns outputs. It does not explain that execution modifies the notebook state (e.g., execution count, output storage), potential errors, or that streaming provides progress updates.
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, front-loaded sentence conveys the core purpose efficiently. Minor grammar issue ('it's' instead of 'its') but overall concise without unnecessary words.
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?
No output schema exists, but the description does not detail the return value format (e.g., output type, error handling). It also omits the precondition of an activated notebook (only implied). For a destructive tool with rich parameters, the description is incomplete.
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 100%, so each parameter is documented. The description adds no extra meaning beyond the schema; it mentions 'with timeout' but the schema already describes the timeout parameter. Baseline 3 is appropriate as no incremental value is provided.
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 the action (execute a cell), resource (cell), and scope (from currently activated notebook). It differentiates from siblings like 'execute_code' by specifying it operates on an existing cell, but does not explicitly contrast with similar tools like 'insert_execute_code_cell'.
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., 'execute_code', 'insert_execute_code_cell'). The context of sibling tools implies a workflow, but the description does not provide any decision criteria or prerequisites beyond 'currently activated notebook'.
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?
The annotation indicates destructiveHint=true, so the tool has destructive behavior. The description adds 'release its resources,' but does not detail what resources (e.g., kernel, memory) are affected or whether the action is reversible. More context is needed to fully inform the agent.
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 sentence with no unnecessary words. However, the phrasing 'Unuse from a specific notebook' is slightly awkward; 'Disconnect from a notebook' would be clearer. Still concise and front-loaded.
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?
For a simple destructive tool with one parameter, the description is somewhat complete. However, it does not mention the return value or side effects beyond releasing resources. With an output schema present, return values are covered there, but more behavioral context would improve completeness.
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 100% (the parameter has a description 'Notebook identifier to disconnect'), so the description does not need to add more. It simply restates that it's for a specific notebook, adding no extra meaning beyond the schema.
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's purpose: 'unuse' from a notebook and release its resources. It distinguishes from sibling tools like connect_to_jupyter or restart_notebook by focusing on disconnecting and cleanup.
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. The description does not specify prerequisites, such as needing to be currently using the notebook, or when not to use it (e.g., if the notebook is needed later).
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?
The description does not add behavior beyond the destructiveHint annotation. Missing details like loss of in-memory variables, unsaved outputs, or impact on concurrent executions.
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?
Extremely concise single sentence, but could be slightly improved by front-loading core information. However, it is not wasteful.
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 is complete for the action but lacks explanation of return value (output schema exists) or side effects beyond destructive hint. Adequate for a simple 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 covers 100% of parameters, and description adds minimal value by repeating 'Notebook identifier to restart'. Baseline 3 is appropriate as schema does the heavy lifting.
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 resource (kernel for a specific notebook), distinguishing it from sibling tools like list_kernels 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 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 when a notebook is unresponsive or before executing new code. No mention of prerequisites or 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?
Annotations already declare destructiveHint=true, indicating mutation. The description adds minimal behavioral context by specifying 'currently activated notebook', implying a dependency on prior state, but doesn't detail effects like shifting other cells, permissions needed, or error handling. With annotations covering the destructive nature, a 3 is appropriate for limited added value.
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 a single, efficient sentence that front-loads the core action ('Insert a cell') and includes essential context ('to specified position from the currently activated notebook'). There is no wasted verbiage, making it highly concise and well-structured.
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 moderate complexity (mutation with 3 parameters), high schema coverage (100%), presence of annotations (destructiveHint), and an output schema (implied by context signals), the description is reasonably complete. It could improve by addressing sibling differentiation or error cases, but it covers the basic operation adequately.
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 100%, with clear documentation for all parameters (e.g., cell_index with -1 for appending, cell_type enum). The description adds no parameter-specific semantics beyond what the schema provides, so it meets the baseline of 3 without compensating for gaps.
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 ('Insert a cell') and the target ('currently activated notebook'), with the positional aspect ('to specified position') adding specificity. However, it doesn't explicitly differentiate from sibling tools like 'insert_execute_code_cell' or 'overwrite_cell_source', which would require a 5.
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?
The description provides no guidance on when to use this tool versus alternatives like 'insert_execute_code_cell' for code execution or 'overwrite_cell_source' for modifying existing cells. It mentions the context ('currently activated notebook') but lacks explicit when/when-not instructions or prerequisites.
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?
Annotations already declare readOnlyHint=true. Description adds that it reads from 'currently activated notebook' and returns metadata, source, and outputs. Does not mention behavior on invalid index or missing notebook, but acceptable for a non-destructive read with annotation support.
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 covering purpose and return value. No filler or redundancy. Minor grammatical issue ('it's' should be 'its') but not affecting clarity.
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 read tool with 2 parameters and no output schema, the description adequately explains inputs and return fields. Missing mention of error conditions (e.g., out-of-range index) but sufficient for most use cases.
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 coverage is 100% with good descriptions for both parameters. Description does not add significant meaning beyond what schema provides. Baseline 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?
Description clearly states 'Read a specific cell' and lists returned data (metadata, source, outputs). Unambiguously distinguishes from siblings like read_notebook (which reads entire notebook) and mutation tools (e.g., delete_cell, edit_cell_source).
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 vs alternatives. Does not mention that it requires an activated notebook (use_notebook) or that include_outputs can be toggled to reduce response size. Lacks all usage context.
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?
The annotations set destructiveHint=true, but the description describes only connecting without any mention of destructive behavior or side effects, failing to add context about what gets destroyed or why the hint is set.
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 concise with a clear structure: first sentence states purpose, second outlines use cases, third gives examples. It avoids fluff but could be slightly tighter.
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?
The description covers purpose, usage scenarios, and examples. With an output schema present, return values are not needed. However, it neglects to clarify the destructive hint, leaving a gap in 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?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, like connecting without a token for no authentication, but does not significantly enhance parameter understanding.
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 Jupyter server with URL and token, distinguishing it from sibling tools that operate on notebooks or files.
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 lists scenarios for use, such as multiple servers, dynamic tokens, and switching instances, with examples. It lacks explicit when-not-to-use but provides clear 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?
Annotations provide readOnlyHint=true, indicating a safe read operation, which the description doesn't contradict. The description adds context by specifying the scope ('notebooks that have been used via use_notebook tool'), which is useful behavioral information beyond annotations. However, it doesn't disclose other traits like rate limits, pagination, or return format, so it's adequate but not comprehensive.
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 a single, clear sentence that efficiently conveys the tool's purpose and scope without any wasted words. It's front-loaded with the main action and appropriately sized for a simple tool, making it highly concise and well-structured.
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 (0 parameters, read-only annotation, and an output schema exists), the description is reasonably complete. It specifies the scope of notebooks listed, which adds value beyond structured fields. However, it could slightly improve by hinting at the output format or usage context, but the presence of an output schema reduces this need.
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 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any, earning a high baseline score for not introducing confusion or redundancy.
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 ('List all notebooks') and specifies a scope ('that have been used via use_notebook tool'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_files' or 'read_notebook', which could have overlapping functionality, so it doesn't reach the highest score.
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 by referencing the 'use_notebook' tool, suggesting it's for notebooks that have been previously accessed. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'list_files' or 'read_notebook', nor does it specify exclusions or prerequisites, leaving some ambiguity.
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?
The description adds value beyond the destructiveHint annotation by clarifying that the cell itself is not deleted, only outputs are cleared. This resolves potential ambiguity about the tool's destructiveness. It does not mention permissions or side effects but sufficiently explains the behavior.
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 a single, clear sentence with no wasted words. It is front-loaded with the key action and context, making it easy to parse quickly.
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?
The tool is simple with one parameter, and there is an output schema present, so return values need not be detailed. The description covers the core functionality adequately. Missing edge cases like invalid indices are minor given the 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?
With 100% schema coverage, the schema already describes the parameter well. The description does not add significant new meaning beyond confirming it operates on a single cell and reiterating the index's role.
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 'clear' and the specific resource 'outputs and execution count of a single code cell'. It also provides context (currently activated notebook) and distinguishes from deleting the cell, making it distinct from siblings like delete_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 does not explicitly state when to use this tool over alternatives. While the context of siblings helps, the description itself lacks guidance on when to use or not use it, such as preferring it over delete_cell to retain the cell.
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?
Annotations provide destructiveHint=true, which the description doesn't contradict. The description adds valuable behavioral context beyond annotations: it specifies what gets returned (cell source when include_source=True), clarifies the operation scope (currently activated notebook), and mentions the conditional return behavior. This provides useful operational details not covered by annotations alone.
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 a single, well-structured sentence that efficiently communicates the core action, target, and key behavioral detail. Every element earns its place with no redundancy or unnecessary elaboration. It's front-loaded with the primary action and appropriately sized for the tool's complexity.
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 destructiveHint annotation, 100% schema coverage, and an output schema (implied by context signals), the description provides adequate context. It covers the main action, target resource, and key return behavior. However, it doesn't mention error conditions, what happens with invalid indices, or dependencies on notebook activation state, which could be helpful for a destructive operation.
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?
With 100% schema description coverage, the schema fully documents both parameters. The description adds minimal semantic context by mentioning include_source parameter's effect on return values, but doesn't provide additional meaning beyond what the schema already states about cell_indices or include_source. This meets the baseline for high 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 specific action ('Delete specific cells'), identifies the target resource ('from the currently activated notebook'), and distinguishes from siblings by specifying it returns cell source (unlike other deletion or modification tools like overwrite_cell_source). It uses precise verb+resource+scope language.
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 context ('currently activated notebook') which suggests it should be used after activating a notebook via use_notebook, but doesn't explicitly state when to use this vs alternatives like overwrite_cell_source or when not to use it. No explicit alternatives or exclusions are mentioned.
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?
Annotations already include destructiveHint: true, so description does not need to add that. It does mention timeout and returning outputs, which adds some context beyond annotations. However, it does not disclose blocking behavior or error scenarios.
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. All information is relevant and 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?
Given 3 params, full schema coverage, no output schema, and sibling tools, the description adequately explains purpose, usage, and relationship to siblings. It does not define 'currently activated notebook' but that may be assumed from 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?
Schema covers all three parameters with descriptions (100% coverage). The description adds 'with timeout' and 'specified index' but no new information beyond the schema's 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?
Description clearly states verb 'Insert a cell and then execute it', identifies the resource (cell in activated notebook), and explicitly calls it a shortcut for insert_cell and execute_cell, distinguishing it from siblings.
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?
Description recommends using this tool when you want to insert and execute simultaneously. It names alternative tools (insert_cell, execute_cell) but does not explicitly state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, but the description adds details on returned fields (IDs, names, states, etc.), which is helpful beyond the annotation.
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 main purpose, no filler. 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 the tool has no parameters and an output schema exists, the description adequately explains the purpose and return content.
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?
No parameters exist, and schema coverage is 100%. Baseline 3 applies since no additional param info 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 'List all available kernels in the Jupyter server' with a specific verb and resource. It distinguishes from sibling tools like list_notebooks by focusing on kernels.
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 says 'Useful for monitoring kernel resources...' but does not explicitly mention when not to use or name alternatives like connect_to_jupyter.
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?
The description explains the destructive behavior (deactivating previous notebook) which aligns with the destructiveHint annotation. It adds context about reactivation and activation effects beyond the annotation.
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 three short sentences that immediately convey the core function and important behavioral notes. 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?
Given the tool's simplicity and the presence of an output schema, the description is nearly complete. It could mention a prerequisite like being connected to Jupyter, but that is implied by the sibling tools.
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 coverage is 100%, so parameters are already well-documented. The description adds minimal extra meaning beyond the schema, mentioning reactivation by name/path but not delving into syntax or format.
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's purpose: to activate a notebook for subsequent cell operations. It distinguishes from siblings like list_notebooks, unuse_notebook, and read_notebook by focusing on activation and state management.
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 when to use (before cell operations) and when to re-activate (use same name/path). It does not explicitly state alternatives or when not to use, but the context is clear enough for an AI agent.
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?
Annotations already provide readOnlyHint=true. Description adds that listing is recursive and supports pattern filtering, which is useful beyond annotations.
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, no filler. Efficiently conveys purpose and usage.
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?
With output schema present, no need to explain return values. Parameters fully described in schema. Description completes the picture for this 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 100%, so baseline 3. Description does not add parameter-specific details beyond what schema already provides.
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 'List all files and directories recursively' and explains its use for exploring file system structure or finding specific files. It is distinct from sibling tools like list_notebooks 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives context for use: exploring file system or finding specific files. Does not explicitly state when not to use or compare to alternatives, but the sibling list_notebooks implies differentiation.
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?
Annotations include destructiveHint=true, which is reinforced by the warning about dangerous code. The description adds transparency about sandbox switching and non-persistence ('not saved to notebook'). However, it does not fully disclose all side effects (e.g., variable assignment persistence despite warning), but the warning covers key risks.
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, recommended uses, and forbidden uses. While somewhat lengthy, every section adds value. Minor redundancy in the bullet points, but overall efficient for the information density.
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 no output schema, the description adequately covers execution environment, constraints, and examples. It explains the dual execution modes and provides useful guidance. It does not describe return values, but the schema covers parameters well and the sibling tools list provides context.
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% with good parameter descriptions. The description adds context beyond the schema by explaining kernel_id's use for raw kernels and the sandbox alternative. It helps agents understand parameter meaning but does not add extensive new details.
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 name 'execute_code' and initial sentence 'Execute code directly in a kernel (not saved to notebook)' clearly convey a specific verb and resource. This distinguishes it from sibling tools like 'execute_cell' (which executes notebook cells) and 'insert_execute_code_cell' (which inserts a new cell and executes).
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 scenarios (6 bullet points for recommended uses) and when-not-to-use (2 forbidden actions). It explains the sandbox vs kernel choice and the role of kernel_id, offering clear context for selecting this tool over 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?
Annotations already set destructiveHint=true. The description adds that the tool returns a diff, which is behavioral insight. However, it does not elaborate on error conditions or permissions, but given annotation coverage, it is sufficient.
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?
Very concise: two sentences for main function plus a usage guideline sentence. No redundant information, front-loaded with purpose and immediate return 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 low complexity (2 required params) and presence of output schema (noting returns a diff), the description is fully adequate. It covers what, when, and return value.
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 100%, so baseline is 3. The description does not add extra semantics beyond the schema's own parameter 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 uses specific verb 'Replace' with resource 'cell source' and mentions it works on the 'currently activated notebook'. It distinguishes from sibling 'edit_cell_source' by stating 'entire source' vs. partial edits.
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 states when to use ('when rewriting a cell completely') and when not ('for small, targeted changes, prefer edit_cell_source'), providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description details the removal, placement, and shifting of cells, and states that cell type, source, and outputs are preserved. It also notes atomicity. Annotations already include destructiveHint=true, and the description adds context beyond that without contradicting it.
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 clear paragraphs: first explains the operation with an example, second provides usage guidance. Every sentence adds value, no redundancy, and the most important info is 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?
With simple integer parameters, a clear schema, and an output schema, the description adequately explains the tool's behavior. It would benefit from mentioning error cases (e.g., out-of-bounds indices) but is complete for typical use.
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% with clear descriptions for both parameters. The description reinforces these by providing an example and explaining the shifting behavior. The example adds practical meaning beyond the schema definitions.
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 'Move a cell from source_index to target_index within the currently activated notebook' with a specific verb-resource pair. Provides an example that clarifies the operation, and the name and description distinguish it from sibling tools like insert_cell, delete_cell, etc.
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?
Explicitly advises using this tool over manual delete and re-insert for atomicity and metadata preservation. Also suggests using read_notebook first to see indices. However, it does not explicitly mention when not to use it or compare with direct sibling 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?
Annotations declare readOnlyHint=true. Description adds behavioral context: pagination via start_index and limit, response content differences between brief and detailed. No contradictions. Could mention if the tool is safe to call repeatedly, but overall good.
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 three paragraphs, each serving a purpose: what it does, usage per format, and recommended workflow. Could be slightly tighter but no wasted sentences. Front-loaded with core function.
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?
For a tool with 4 parameters and output schema (not shown but exists), description covers all key aspects: pagination, format details, and best practices. Sufficient for agent to invoke correctly without ambiguity.
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 description coverage is 100%, so baseline is 3. Description adds value by explaining that brief returns first line and line count, detailed returns full source, and gives usage advice for combining both. This augments the schema's parameter 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?
Description clearly states it reads a notebook and returns per-cell details (index, source, type, execution count). It distinguishes between brief and detailed formats. Siblings like list_notebooks or restart_notebook are distinct operations.
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?
Explicit guidance is provided: brief for overview, detailed for debugging, and recommends using brief first then detailed for specific cells. This helps the agent choose the correct format and limit settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: literal matching (not regex), multi-line support, default uniqueness of old_string, and replace_all option. Mentions return of a diff. Annotations include destructiveHint: true, which is consistent with description's 'safer' claim. No contradictions.
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 concise (4 sentences) and well-structured: first sentence states core purpose, second explains mechanics, third provides usage guidance and alternative, fourth suggests prerequisite action. No unnecessary words.
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?
Covers all essential aspects: purpose, mechanics, constraints, usage guidance, comparison with alternative, prerequisite, and return value (diff). Given 4 parameters, 3 required, and presence of output schema, the description is complete for agent to select and invoke correctly.
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 covers 100% of parameters with descriptions. Description adds nuance: literal matching, multi-line, default uniqueness behavior for old_string, and semantics of replace_all (default first only). This adds meaningful context beyond 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?
Clearly states the tool performs a surgical find-and-replace on a cell's source, using specific verb (edit) and resource (cell source). Explicitly distinguishes from sibling overwrite_cell_source by contrasting targeted edits vs full overwrite.
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 advises when to use: prefer for small targeted edits over overwrite_cell_source. Recommends reading the cell first with read_cell to construct an accurate old_string. Provides clear usage conditions.
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/datalayer/jupyter-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/datalayer/jupyter-mcp-server)

Score Badge

Copy to your README.md:

[![jupyter-mcp-server MCP server](https://glama.ai/mcp/servers/datalayer/jupyter-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/datalayer/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/datalayer/jupyter-mcp-server'

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