Skip to main content
Glama
jonasliesas

singlestore-mcp-server

by jonasliesas

notebook_kernel_start

Read-only

Start a notebook's Python kernel before the first cell runs, so the environment is ready without executing code. Requires notebook_id.

Instructions

Start the notebook's Python kernel ahead of the first cell (no code runs).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notebook_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is partly covered. The description usefully clarifies '(no code runs)', which explains why a kernel-start operation is non-destructive, but says nothing about idempotency if a kernel is already running, latency, or whether the notebook must be open. Adds some context beyond annotations, not rich 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?

A single front-loaded sentence with no filler; the scoping clarification sits in a tight parenthetical rather than bloating the 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?

For a one-parameter tool with no output schema, the description covers the essentials of what the tool does and its non-destructive nature. It omits prerequisites (must the notebook be open?) and behavior when a kernel already exists, which are relevant for a kernel lifecycle 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 coverage is 0% and the description never addresses notebook_id, so it adds no meaning beyond the schema. However, with a single, self-evidently named identifier parameter, the practical risk of misinterpretation is low, so an adequate-but-minimal 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Start the notebook's Python kernel') and adds the timing nuance 'ahead of the first cell'. It is distinguishable from notebook_run (which runs code) and notebook_kernel_state, though it does not explicitly name those siblings.

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 phrase 'ahead of the first cell' implies the use case: pre-warming the kernel before executing cells. It never explicitly states when to use this instead of notebook_run or notebook_kernel_control, leaving the routing to inference from the tool name.

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

Deploy Server

Other Tools