Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_active_notebooksA

List currently active marimo notebooks.

Returns all active sessions with their file paths and session IDs. The first discovered session is automatically bound as the active session, so later calls that share this MCP session can omit both session_id and server_url.

The binding is server-side state keyed by the MCP session identity the client negotiates, so it reaches the next call only when the client keeps one MCP session for the connection — an mcp-SDK-based client does, fastmcp's own Client does not on the pinned fastmcp 4.0.3 (it starts a new session per request). Where that is the case, pass session_id and server_url explicitly on every call.

get_cell_mapA

Get a lightweight map of cells showing previews.

Returns cell IDs, names, code previews, and runtime state. This is the starting point for navigating a notebook.

A preview does NOT record the edit_cell read baseline — it updates only this tool's own change-detection snapshot. Read a cell's full source with get_cell_data before editing it.

get_cell_dataA

Get full runtime data for one or more cells.

Includes source code, errors, and variable information. If cell_ids is empty, returns data for all cells.

A requested id that resolves to nothing (deleted or mistyped) is reported in missing_cell_ids rather than silently omitted — the write tools refuse an absent id, so an unqualified empty payload here would hide the same mistake.

get_cell_outputsB

Get cell execution outputs including visual display and console streams.

A requested id that resolves to nothing (deleted or mistyped) is reported in missing_cell_ids rather than silently omitted — a cell with no output and a cell that does not exist must not look alike.

get_variablesA

Get tables and variables information in the session.

Returns information about kernel variables and DataFrames. If variable_names is empty, returns all variables — meaning the notebook's own session names, with the inspection template's scaffolding (its imports and helpers) excluded, since the scratchpad shares the kernel namespace.

get_dependency_graphB

Get the cell dependency graph showing variable relationships.

Reveals which variables each cell defines and references, parent/child relationships between cells, variable ownership, and dependency issues like multiply-defined variables or cycles. The graph is always the FULL notebook graph.

get_errorsA

Get all errors in the notebook session, organized by cell.

Two channels are reported and never conflated:

  • structured_errors: marimo's structured CellError records (kind graph|runtime, msg, exception).

  • console_stderr: serialized stderr console events (same shape as get_cell_outputs), so UI-handler exception tracebacks are visible even when the structured channel is empty.

has_errors / total_errors / total_cells_with_errors are the STRUCTURED-only counts (backward-compatible); has_console_exception / total_console_exception_cells cover the console channel.

lint_notebookB

Lint a marimo notebook to check for issues.

Uses marimo's internal linting engine (the same one behind marimo check) to check for:

  • Breaking issues: Problems that prevent the notebook from running

  • Runtime issues: Problems that may cause unexpected behavior

  • Formatting issues: Code style and formatting problems

set_active_sessionA

Set the active notebook session for subsequent tool calls.

Binds a session_id (and optionally its server_url) so later calls can omit both session_id and server_url. The binding is written to two places: this call's MCP-session state (visible to a client that keeps one MCP session across calls — an mcp-SDK-based client does) and a process-global fallback consulted only when the MCP-session state has nothing bound. Over stdio one process serves exactly one client, so the fallback carries the binding to every later call, fastmcp's own Client (a fresh MCP session per request on the pinned fastmcp 4.0.3) included. Over HTTP/SSE one process serves many clients, so the fallback is served only while the process has seen a single client session; once a second distinct client session appears, argument-less calls are refused with reason: binding_ambiguous rather than risk handing one client another client's notebook — pass both arguments explicitly there. Use list_active_notebooks first to discover available sessions and their IDs.

create_cellB

Create a new cell in the notebook.

Created cells are visible in the UI by default (hide_code=False); pass hide_code=True explicitly for setup/implementation cells you want hidden.

edit_cellA

Edit an existing cell's source code.

Includes a staleness guard: unless check_fresh=False, refuses to edit a cell that has no full-source read baseline (needs_read) or whose source changed since that read (conflict). get_cell_data records the baseline; a get_cell_map preview does not. This prevents silently overwriting a concurrent edit.

run_cellC

Run (execute) an existing cell.

delete_cellC

Delete an existing cell from the notebook.

set_ui_valueA

Set the value of a live marimo UI element, by its variable name.

The kernel global named by variable_name must resolve to a marimo UI element (e.g. mo.ui.slider, mo.ui.dropdown, mo.ui.text). Its value is replaced with value, triggering reactive re-execution the same way a user interaction would.

Value shape is per widget and is NEVER coerced: a slider/text takes a scalar, a dropdown takes its option key inside a one-element list (for example ["beta"]), a multiselect takes the list of selected keys, a range_slider takes a two-element list, a checkbox takes a bool. The element's own declaration decides; a shape mismatch is refused before anything is applied and the response carries the corrected payload in did_you_mean.

This tool accepts NO source code: it exists for widget interaction only, not for arbitrary code execution. The update is flushed on code-mode context exit, the kernel then re-runs dependent cells, and the element's value is read back before returning — status: ok with verified: true means the element's own value was observed to move (or was already equal), not merely that the update was queued. A value marimo rejected is reported as an error, never as success.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
Co-work loopThe MCP-first co-work loop on a live notebook: discover/bind, orient, read, write/run, interact, verify, lint — with exact tool names and the read-before-edit rule.
Live-safety rulesSafety rules for editing a live kernel: read-before-edit, the needs_read/conflict recovery protocol, dependency checks before delete/merge, post-write verification, and widget visibility.
Fallbacks and limitsWhat the MCP surface does not cover and the intentional fallbacks: output coverage, widget value shape, frontend refresh, screenshots, server lifecycle, and the script hatch.

TDQS

A3.7/5.0

Scored across 14 tools

Disambiguation4/5

The 14 tools generally have distinct purposes, but get_cell_map, get_cell_data, and get_cell_outputs all involve retrieving cell information and could be confused by an agent unfamiliar with the subtle differences. The descriptions do clarify the differences (preview vs full data vs outputs), so it's mostly distinct.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (get_*, list_*, create_*, edit_*, run_*, delete_*, set_*), with no deviations. The naming is predictable and readable.

Tool Count5/5

The server has 14 tools, which is well within the typical 3-15 range for a well-scoped MCP server. Each tool appears to earn its place by covering a specific operation in notebook inspection and manipulation.

Completeness4/5

The toolset covers a broad range of notebook operations (cell CRUD, execution, outputs, errors, linting, variables, dependency graph, UI interaction, session management), but some potential gaps exist, such as creating or deleting notebooks, managing files, or deeper kernel operations. It is largely complete for inspection and basic editing.

Maintenance

ActivityMaintained
ResponsivenessNo issues