jlab-mcp

by kdkyum

Overview Schema Related Servers Score Discussions

Python

Remote

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: adding markdown, editing cells, executing code, and managing sessions (shutdown, start new, continue, resume). There is no overlap in functionality that would cause confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case (e.g., add_markdown, edit_cell, execute_code). The naming is predictable and readable throughout the set.
Tool Count5/5
With 7 tools, this server is well-scoped for Jupyter notebook management. It covers core operations (session lifecycle, code execution, cell editing) without being overly sparse or bloated.
Completeness4/5
The toolset provides comprehensive coverage for notebook operations, including session management and cell manipulation. A minor gap is the lack of a tool to delete cells or manage notebook files beyond forking/resuming, but agents can work around this.
Average 3.7/5 across 7 of 7 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 provided, the description carries full burden but provides minimal behavioral context. It mentions that editing triggers re-execution and output updates, but doesn't cover important aspects like error handling, permission requirements, whether changes are reversible, or side effects on other cells/sessions.
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 appropriately sized and front-loaded with the core functionality. The Args/Returns sections are structured but could be more integrated. Every sentence adds value, though the formatting is slightly verbose.
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 3 parameters with 0% schema coverage and no annotations, the description provides basic parameter semantics and mentions the return format. However, for a mutation tool that edits and executes code, it lacks sufficient context about behavioral implications, error conditions, and integration with sibling tools. The output schema exists, reducing the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides basic semantic meaning for all three parameters (session_id as identifier, cell_index with negative indexing support, code as new content), but lacks details about format constraints, valid ranges, or examples. This meets the baseline for 0% coverage.
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 with specific verbs ('edit', 're-execute', 'update') and identifies the resource ('existing cell'). It distinguishes this from siblings like 'add_markdown' (creation) and 'execute_code' (execution only), but doesn't explicitly contrast with all siblings like session management tools.
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 is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an active session), exclusions, or comparisons to similar tools like 'execute_code' for execution without editing.
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?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions that execution occurs 'in the kernel' and 'add[s] cell to notebook,' but lacks details on permissions, error handling, rate limits, or whether this is a read-only or destructive operation. The phrase 'Execute code' implies mutation, but this isn't explicitly confirmed.
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 appropriately sized and front-loaded, with the core purpose stated first, followed by parameter and return explanations. However, the 'Args:' and 'Returns:' sections could be integrated more smoothly, and some redundancy exists (e.g., 'Execute code' and 'code: Python code to execute').
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 tool's complexity (code execution in a kernel), no annotations, and an output schema present (which covers return values), the description is moderately complete. It explains parameters and returns but lacks crucial context like session prerequisites, safety warnings, or differentiation from siblings, leaving gaps for an AI agent.
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 0%, but the description compensates by explaining both parameters: 'session_id: Session identifier' and 'code: Python code to execute.' This adds clear meaning beyond the bare schema, though it doesn't specify formats or constraints (e.g., session_id format, code limitations).
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: 'Execute code in the kernel and add cell to notebook.' This specifies the verb ('Execute'), resource ('code'), and context ('kernel', 'notebook'), though it doesn't explicitly differentiate from siblings like 'edit_cell' or 'start_session_continue_notebook'.
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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites like needing an active session, nor does it clarify distinctions from sibling tools such as 'edit_cell' (which might modify existing cells) or session management tools.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this adds a cell and returns a confirmation with cell index, which is basic. However, it doesn't cover important behavioral aspects: whether this requires specific permissions, if it modifies notebook state permanently, what happens on errors, or if there are rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
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 and well-structured: a clear purpose statement followed by separate 'Args' and 'Returns' sections. Every sentence earns its place by providing essential information without redundancy. The formatting with bullet-like sections enhances readability while maintaining brevity.
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 tool's moderate complexity (adding content to a notebook), no annotations, and an output schema that presumably covers the return value, the description is minimally adequate. It explains what the tool does and documents parameters, but lacks behavioral context like error handling or side effects. The presence of an output schema means the description doesn't need to detail return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents both parameters ('session_id' and 'markdown') with brief explanations, adding meaningful context beyond the schema's 0% description coverage. It clarifies that 'session_id' identifies the session and 'markdown' is the content, which compensates well for the schema's lack of descriptions. With only 2 parameters, this provides adequate semantic information.
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 verb ('Add') and resource ('markdown cell to the notebook'), making the purpose immediately understandable. It distinguishes this from siblings like 'edit_cell' or 'execute_code' by specifying it's for adding markdown content rather than editing existing cells or running code. However, it doesn't explicitly contrast with 'start_new_session' or other session management tools.
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 'edit_cell' for modifying existing cells or 'execute_code' for code cells. It doesn't mention prerequisites such as needing an active session (implied by session_id but not stated) or when markdown cells are appropriate versus other cell types.
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 provided, the description carries full burden. It discloses key behavioral traits: it's a destructive operation (shutdown/stop/cancel) and mentions both kernel and SLURM job termination. However, it doesn't address permissions needed, whether changes are reversible, or error conditions, leaving gaps in 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 efficiently structured with a clear purpose statement followed by separate Args and Returns sections. Every sentence earns its place by providing necessary information without redundancy, making it easy to parse and understand.
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 complexity (destructive operation), no annotations, and an output schema (which handles return values), the description is reasonably complete. It covers purpose, parameter meaning, and return confirmation, though could benefit from more behavioral details like prerequisites or side effects.
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% schema description coverage and only 1 parameter, the description adds essential meaning by explaining 'session_id' as a 'Session identifier', which clarifies what the parameter represents beyond just its name. This compensates well for the lack of schema documentation.
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 with specific verbs ('shutdown', 'stop', 'cancel') and resources ('session', 'kernel', 'SLURM job'), distinguishing it from sibling tools like start_new_session which have opposite functions. It precisely communicates the tool's destructive termination action.
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 usage context by specifying it's for shutting down sessions, suggesting it should be used when a session is no longer needed versus starting tools. However, it doesn't explicitly state when-not to use it or name specific alternatives, missing full explicit 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 provided, the description carries the full burden of behavioral disclosure. It mentions the actions (submit job, start kernel, create notebook) but omits details like required permissions, potential side effects (e.g., resource allocation), or error handling. It adds some context but falls short of fully describing behavioral traits for a tool that initiates processes.
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 front-loaded with the core purpose in the first sentence, followed by structured sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
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 complexity (initiates multiple operations) and no annotations, the description does well by outlining actions, parameters, and return values. The presence of an output schema reduces the need to detail returns, but it could benefit from more behavioral context, such as execution time or failure modes, to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides the parameter 'experiment_name' with a clear meaning ('Name for the experiment/notebook'), adding essential semantics beyond the schema. However, it doesn't specify constraints like length or allowed characters, leaving some gaps.
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 ('Start a new session') and enumerates the three concrete operations it performs: 'submit SLURM job, start kernel, create notebook.' It distinguishes itself from sibling tools like 'shutdown_session' or 'start_session_continue_notebook' by emphasizing it's for initiating a new session from scratch.
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 usage context by specifying it's for starting a 'new session,' which differentiates it from siblings like 'start_session_continue_notebook' or 'start_session_resume_notebook' that handle existing sessions. However, it lacks explicit guidance on when not to use it or detailed prerequisites, such as whether prior setup is needed.
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 provided, the description carries the full burden. It discloses key behavioral traits: the tool performs re-execution of all cells to restore kernel state, which implies mutation and computational effects. However, it doesn't mention permissions, rate limits, or error handling details, leaving gaps for a tool with significant behavioral impact.
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 front-loaded with the core purpose in the first sentence, followed by structured sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and well-organized for quick comprehension.
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 complexity (resuming sessions with re-execution), no annotations, and an output schema that documents return values, the description is mostly complete. It covers purpose, parameters, and returns, but could benefit from more behavioral context like prerequisites or side effects to fully guide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% coverage. It explains that 'experiment_name' is for naming the session and 'notebook_path' is the path to an existing notebook to resume, clarifying their roles. Since there are only 2 parameters and the description covers both adequately, it compensates well for the schema's lack of 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 the specific action ('resume a notebook: re-execute all cells to restore kernel state'), identifies the resource (notebook), and distinguishes it from sibling tools like 'start_new_session' and 'start_session_continue_notebook' by emphasizing re-execution for restoration.
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 usage context by specifying 'resume a notebook' and 'existing notebook to resume', suggesting it's for restarting prior sessions rather than creating new ones. However, it lacks explicit guidance on when to use alternatives like 'start_new_session' or 'start_session_continue_notebook'.
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 provided, the description carries the full burden of behavioral disclosure. It describes key behaviors: forking a notebook, using a fresh kernel, and not re-executing code. However, it lacks details about permissions, rate limits, session lifecycle, or error conditions. For a session management tool with zero annotation coverage, this is a moderate gap.
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 perfectly structured and concise: a one-sentence purpose statement followed by clearly labeled Args and Returns sections. Every sentence earns its place with no wasted words, and key information 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?
Given the tool's moderate complexity (session management with forking), no annotations, and an output schema that documents return values, the description is reasonably complete. It covers purpose, parameters, and return structure, though additional behavioral context (like auth or error handling) would improve completeness.
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 0%, so the description must compensate. It provides clear semantic explanations for both parameters: 'experiment_name: Name for this session' and 'notebook_path: Path to existing notebook to fork'. This adds meaningful context beyond the bare schema types, though it doesn't cover format details 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?
The description clearly states the tool's purpose with specific verbs ('continue a notebook', 'fork it with fresh kernel') and distinguishes it from sibling tools like 'start_new_session' and 'start_session_resume_notebook' by specifying 'no re-execution'. It precisely identifies the resource (notebook) and action (forking with fresh kernel).
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 explicitly provides usage guidance by stating 'continue a notebook: fork it with fresh kernel (no re-execution)', which clearly differentiates it from alternatives like 'start_session_resume_notebook' (which likely resumes with execution) and 'start_new_session' (which doesn't fork an existing notebook). It tells the agent exactly when to use this tool versus its siblings.
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:

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

Score Badge

Copy to your README.md:

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

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/kdkyum/jlab-mcp'

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