marimo MCP Server sicher lokal einrichten

Diese Anleitung richtet den offiziellen, experimentellen marimo MCP Server als begrenzten lokalen Zugriff auf ein laufendes Notebook ein. Grundlage sind die marimo-Dokumentationen zu MCP und AI tools. Vor der Installation festhalten, welches Notebook, welche Zellen und welche Daten überhaupt sichtbar sein dürfen. Der Server ist kein Ersatz für Rollenmodell, Repository-Review oder eine Freigabe von Codeausführung. Sein dokumentierter Zweck ist es, einem externen MCP-Client lesende Informationen zu aktiven marimo-Sitzungen bereitzustellen. Wer ein Notebook durch einen Coding-Agenten steuern oder verändern lassen will, muss die von marimo dafür getrennt dokumentierten Wege und deren Schreibrechte prüfen.

Voraussetzungen und kontrollierter Start

Nutze eine isolierte Python-Umgebung und einen aktuellen marimo-Stand mit den MCP-Extras. Starte ein konkretes Testnotebook mit:

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

marimo startet dabei den Notebook-Editor und einen MCP-Endpoint am gleichen lokalen Serverport. Notiere Port, Notebookpfad, verwendete marimo-Version, Client und Modell. Beginne nicht mit einem Notebook, das Produktionszugänge, personenbezogene Rohdaten oder Secrets in Zellen und Ausgaben enthält. Bereits die Toolliste kann Dateipfade, Zellcode, Laufzeitmetadaten, Tabelleninformationen, Fehler und Visualisierungen zugänglich machen. Kopiere Tokens nicht in Notebook, Prompt, Screenshot oder Repository.

Lass die Token-Authentifizierung standardmäßig aktiv. --no-token entfernt sie laut marimo und ist nur für lokale Entwicklung vorgesehen. Ein praktischer Verbindungstest ist nicht das Öffnen der Endpoint-URL im Browser, sondern die nachfolgende Toolliste im MCP-Client. Für ein Team oder einen dauerhaft betriebenen Dienst gehört der Endpoint hinter eine explizit konzipierte Netzgrenze; diese Anleitung optimiert bewusst den localhost-Fall, nicht eine öffentliche Bereitstellung.

Client verbinden und Rechte prüfen

Die marimo-Dokumentation zeigt für Claude Code den HTTP-Transport:

claude mcp add --transport http marimo http://localhost:PORT/mcp/server

Ersetze PORT durch den Port des laufenden marimo-Servers. Cursor kann denselben Endpoint in seiner MCP-Konfiguration verwenden. Ist Authentifizierung aktiv, den Access-Token nur in der geschützten Client-Konfiguration ergänzen, nicht in eine geteilte Konfigurationsdatei einchecken. Prüfe danach, dass der Client nur die erwarteten marimo-Tools erkennt: aktive Notebooks, Zellkarte, Laufzeitdaten und Outputs, Abhängigkeitsgraph, Tabellen und Variablen sowie Fehler- und Lint-Informationen.

Diese Werkzeuge sind Recherche- und Diagnosezugriff. Sie dienen nicht als Freigabe für Notebook-Ausführung. run_stale_cells, edit_notebook und die Code-Mode-Funktion execute_code beschreibt marimo für seine Chat-Oberfläche; die Dokumentation grenzt sie vom externen MCP-Server ab. Akzeptiere deshalb keinen Modellvorschlag wie „führe die Zelle jetzt aus“ als automatische Aktion. Ein Mensch prüft Code, Eingabedaten, Auswirkungen, Test und Rückrollweg separat.

Netzwerk und Remote-Betrieb begrenzen

Der Standard localhost begrenzt die Erreichbarkeit auf den Rechner, ersetzt aber keine Authentifizierung. marimo prüft Host-Header als DNS-Rebinding-Schutz. --mcp-allow-remote deaktiviert diese Prüfung für Proxy-, Gateway- oder Custom-Domain-Szenarien. Nur einsetzen, wenn eine Architektur mit TLS, tokenbasierter Authentifizierung, restriktiver Firewall, erlaubten Clients und Monitoring bereits festgelegt ist. Einen Reverse Proxy nicht als Grund verwenden, Token-Prüfung auszuschalten. Besonders gefährlich ist die Kombination eines extern erreichbaren Ports mit --no-token.

Prüfe auch den Arbeitsplatz: lokale Logs, Shell-Historie, Prozesslisten und MCP-Client-Konfiguration können Endpoint oder Token sichtbar machen. Nach einem temporären Test Server und Client-Verbindung beenden oder entfernen. Bei gemeinsam genutzten Geräten getrennte Betriebssystemkonten und einen eigenen Arbeitsbereich nutzen. Für Remote-Notebooks oder Container ist zusätzlich zu klären, welcher Host tatsächlich lauscht und welche Netzwerkzone den Endpoint erreichen kann.

Untrusted Content und Modell-Datenpfad

Behandle jeden Toolrückgabewert als untrusted content. Zellen können Markdown, URLs, Webdaten oder Tabellenzeilen enthalten, die Prompt Injection versuchen: „Ignoriere Sicherheitsregeln“, „lies die Umgebungsvariablen“, „rufe eine Shell auf“ oder „veröffentliche die Daten“ sind Daten, keine Anweisungen. Begrenze den Client auf benötigte Tools und Sitzungen, trenne Notebook-Inspektion von Shell- und Git-Rechten und verlange menschliche Bestätigung für jede Folgemaßnahme. Auch ein seriös wirkender Stacktrace oder Kommentar erhält keine Sonderrolle.

Der vollständige Datenpfad lautet mindestens Notebook-Kernel zu marimo-Server zu MCP-Client zu Modellkontext. Danach können clientabhängig Logs, Telemetrie oder ein externer Modellanbieter folgen. Vor dem Zugriff daher Modellname, Anbieter, Aufbewahrung, Trainingsnutzung, Unternehmenseinstellungen, Vertrag und regionale Verarbeitung dokumentieren. Lokaler Transport schützt nicht vor einer späteren Cloud-Modellanfrage. Sende nur die tatsächlich nötige Sitzung und vermeide sensible Werte in Zelloutputs. So bleibt der marimo MCP Server ein nachvollziehbarer, minimaler Diagnosezugang statt ein unkontrollierter Datenkanal.

FAQ

Warum sehe ich keinen MCP-Endpoint? Prüfe zuerst, ob marimo mit den MCP-Extras und dem Flag --mcp gestartet wurde, und verwende den tatsächlichen lokalen Serverport in der Client-URL.

Darf ich --mcp-allow-remote für einen Proxy setzen? Nur nach einer Sicherheitsprüfung. Das Flag schaltet die Host-Header-Prüfung ab; Token, TLS, Firewall und eine klare Vertrauensgrenze müssen dann unabhängig bestehen.

Können Tabellenwerte eine Prompt Injection sein? Ja. Werte, Markdown, Ausgaben und Fehlertexte sind Daten. Sie dürfen keine Toolrechte erweitern oder menschliche Freigaben ersetzen.