marimo MCP Server

The marimo MCP Server is marimo's documented, currently experimental interface for external MCP-compatible applications. It is not operated as a standalone SaaS endpoint: starting a local marimo notebook with --mcp makes the running marimo process serve an HTTP endpoint. A connected client such as Claude Code or Cursor can use marimo's AI tools against active notebook sessions. The official documentation explicitly calls this feature experimental and under active development, so tool definitions, availability, and APIs can change. That is a reason to re-check the version, client, and configuration before every production use involving confidential data.

Notebook inspection, not notebook execution

The MCP server is intended for low-level, read-only interaction with a live notebook. It can list active notebooks with session IDs and file paths, inspect cell structure, retrieve complete cell code and runtime data, inspect outputs, trace dependencies, inspect variables and table metadata, and summarise errors or lint findings. This can support debugging, data analysis, code review, and orientation inside reactive Python notebooks. It is not notebook execution: marimo documents run_stale_cells, notebook editing, and Code mode execution for its own chat UI, not as an exposed MCP write interface. The MCP guide specifically calls the external server lower-level read-only tools and points people who want a coding agent to drive a live notebook to marimo pair.

This boundary matters. A model may analyse code, variables, table metadata, errors, and cell outputs and suggest changes, but this endpoint should not be treated as authority to run or modify cells. Review suggestions separately in the notebook and version-control system. Even read-only results can contain sensitive research data, personal values, credentials printed in output, internal file paths, or proprietary Python code. Limit started notebooks and exposed data to the smallest test scope that answers the task.

Local HTTP endpoint and network boundary

The official guide shows, for example, uv run --with="marimo[mcp]" marimo edit notebook.py --mcp. For local development it also permits --no-token, but marimo warns that this removes authentication and should not be used in production environments. The endpoint is http://localhost:PORT/mcp/server for the marimo server port; with authentication enabled, the client must include the documented access token. A local process is not synonymous with a secure or automatically private interface. Publishing its host or port through a reverse proxy exposes network access to notebook tools.

marimo enables DNS-rebinding protection and validates incoming Host headers. --mcp-allow-remote disables that check for proxies, gateways, or custom domains. It is not a harmless convenience switch: use remote exposure only with an authenticated client, restrictive firewall and bind configuration, TLS at the appropriate boundary, and a documented trust boundary. Do not combine --no-token and --mcp-allow-remote merely to make an endpoint quickly reachable. For a personal test, authenticated localhost has the smallest attack surface.

Code, data, prompt injection, and the model path

Cell code, Markdown, table values, HTML output, tracebacks, and file paths are untrusted content. They can contain misleading instructions or prompt injection, such as requests to ignore rules, read local secrets, or invoke more tools. A client or agent must treat that material only as data. Constrain tool permissions, query only necessary sessions, review sources and code changes with a human, and never treat an embedded notebook instruction as authorization. A read-only MCP server also does not protect against a client that has shell, Git, or write-capable tools in parallel.

The data path does not automatically stop at the local marimo process. marimo returns tool results to the connected MCP client, which can put them in logs, telemetry, or the context of a local or hosted model provider. A local notebook and local endpoint therefore do not guarantee local model processing. Identify the client, model provider, retention, training settings, contract, and regional processing before notebook content is transmitted. The public source is Apache-2.0 licensed. On 2026-09-08, the GitHub API reported exactly 22,685 stars for marimo-team/marimo; that count covers the complete marimo monorepo, including the notebook platform, not the MCP server alone, and is not evidence of security or quality.

FAQ

Can an external MCP client execute notebook cells? The MCP guide describes the external server as access to low-level, read-only tools. Execution and editing are not a documented MCP-server permission.

When is --no-token acceptable? marimo says it is only for local development. Keep authentication enabled for a reachable or production endpoint.

Does localhost keep data local to the model? Not automatically. The MCP client can pass tool results to its selected model provider, logs, or telemetry.

A Python environment with marimo and its MCP extras, a running marimo notebook, an MCP-compatible client, and local access to the marimo HTTP port.

Start the notebook with uv run --with="marimo[mcp]" marimo edit notebook.py --mcp. Leave authentication enabled, identify the displayed port, and configure the client with http://localhost:PORT/mcp/server. In Claude Code use claude mcp add --transport http marimo http://localhost:PORT/mcp/server. Add --no-token only for a local development test.

uv run --with="marimo[mcp]" marimo edit notebook.py --mcp

marimo uses an access token unless --no-token is set. The official guide limits disabling authentication to local development.

Read-oriented access to active notebook sessions, cell code, runtime data, outputs, dependencies, variables, table metadata, and error/lint information. Notebook execution and editing are not documented as external MCP write capabilities.

marimo sends requested notebook information to the MCP client. That client can pass results to logs, telemetry, or a local or hosted model provider; localhost does not automatically constrain that downstream path.

Cell code, outputs, data, and errors can expose sensitive information or prompt injection. Further risks come from --no-token, remote exposure, and a client with additional write tools. Keep authentication, localhost, least privilege, and human review.