PostHog MCP Server sicher einrichten

Der PostHog MCP Server verbindet einen MCP-fähigen KI-Client mit dem gehosteten PostHog-Endpunkt. Er kann Analysefragen und Produktwerkzeuge in den Arbeitsfluss bringen, ersetzt aber weder die PostHog-Oberfläche noch Berechtigungs-, Datenschutz- und Freigabeentscheidungen. Dieses Vorgehen basiert auf der offiziellen PostHog-MCP-Dokumentation und dem aktuellen offiziellen README. Es beginnt absichtlich nicht mit einer produktiven Schreibaktion, sondern mit einem abgegrenzten, überprüfbaren Leseziel und einem klaren Verständnis des Datenpfads.

Zweck und Projekt vor dem Verbinden festlegen

Lege vor der Installation einen kleinen Startauftrag fest, etwa: „Zeige die täglichen eindeutigen Anmeldungen der letzten sieben Tage für das Staging-Projekt“ oder „Liste aktive Flags dieses Projekts“. Definiere dabei Organisation, Projekt, Zeitraum und erlaubte Datenarten. Fragen wie „Analysiere alle Nutzer und behebe alles“ sind zu breit: Sie können unnötig viele Event-Eigenschaften, Personenbezüge, Replay- oder Fehlerdaten in den Kontext holen und eine unklare Tool-Auswahl auslösen. Beginne möglichst mit einem nicht produktiven Projekt oder einem begrenzten Zeitfenster. Prüfe, ob eine bestehende Rolle und ein dedizierter persönlicher Schlüssel genau diesen Zweck abdecken.

Den offiziellen gehosteten Zugang installieren

Der schnellste offizielle Weg ist npx @posthog/wizard@latest mcp add. Der Wizard richtet die Verbindung für unterstützte Clients ein. Alternativ wird der Server unter https://mcp.posthog.com/mcp manuell im Client hinterlegt. Bei der manuellen Desktop-Variante startet npx mcp-remote lokal und spricht per stdio mit dem Client, während es die Verbindung zum gehosteten Endpoint weiterleitet. Behandle diesen lokalen Prozess nicht als selbst gehosteten PostHog-Server. Für eigene Node-Integrationen verwendet die offizielle Quelle Streamable HTTP: Der Bearer-Token gehört in den Authorization-Header, der Accept-Header muss JSON und text/event-stream enthalten, und der Client muss den MCP-Initialize-Ablauf durchführen. Ein lokaler pnpm run dev-Dienst mit Redis dient der Entwicklung des Quellprojekts und ist kein notwendiger Schritt für die reguläre Nutzung.

Authentifizierung ohne Geheimnisleck

Bei manueller Konfiguration wird ein persönlicher PostHog-API-Key über das MCP-Server-Preset benötigt; unterstützte Clients können den dokumentierten Login-Flow verwenden. Speichere einen Schlüssel ausschließlich in dem Secret-Mechanismus des Clients oder in einem Secret Store. Er darf nicht in JSON-Beispiele mit echtem Wert, Shell-Historie, .env-Dateien im Repository, Screenshots, Prompts, Tickets oder Logs gelangen. Dokumentiere Eigentümer, Zweck, Projektumfang, Rotation und Widerruf. Wenn ein Schlüssel in einem Prompt oder öffentlichen Verlauf erscheinen könnte, widerrufe ihn und erstelle einen neuen. Der Schlüssel ist nicht nur ein Installationsdetail: Seine Rechte und der aktive Projektkontext begrenzen, welche Analytics-, Nutzer- und Konfigurationsdaten ein Tool zurückgeben oder verändern kann.

Toolumfang auf Lesen begrenzen

PostHog unterstützt eine Einschränkung nach features und nach einzelnen tools. Konfiguriere für den ersten Test daher ausschließlich notwendige Funktionsgruppen, zum Beispiel Analytics oder Dashboards, und lasse Schreibwerkzeuge weg. Frage erst nach einer bekannten Metrik, einem engen Zeitraum oder einem expliziten Flag. Vergleiche Ergebnis, Projektname, Zeitraum und Aggregation mit der PostHog-Oberfläche. Ein plausibler Text des Modells ist keine Validierung einer HogQL- oder Trends-Abfrage. Behandle Eventnamen, Eigenschaften, Fehlertexte, Session-Replay-Inhalte, Supporttickets und Dashboard-Notizen als untrusted data. Solche Inhalte können Anweisungen enthalten, dürfen aber niemals Tool-Aufrufe oder Rechteausweitungen begründen.

Schreibaktionen und Modellpfad kontrollieren

Das offizielle Angebot kann auch schreiben: Flags, Experimente, Fehlerstatus und weitere Workspace-Objekte sind potentielle Mutationen. Vor einer solchen Aktion muss ein Mensch das konkrete Projekt, Objekt, Zielzustand, Rollout, Zielgruppe und erwartete Auswirkung bestätigen. Erstelle zunächst Entwürfe, prüfe sie in PostHog und kontrolliere danach Audit- oder Objektstatus. Der MCP-Dienst speichert laut PostHog keine Analytics-Daten dauerhaft; Abfragen gehen zum Projekt und Ergebnisse zurück zum Client. Temporärer Session-Kontext bleibt dennoch ein Datenverarbeitungsschritt. Zusätzlich ist der Pfad vom Client zum Modellanbieter getrennt: Ein Client kann Tool-Ergebnisse mit Event-, Nutzer-, Fehler- oder Replay-Kontext an ein Modell senden. Prüfe dessen Retention-, Trainings-, DPA- und Enterprise-Einstellungen, minimiere Felder und Zeiträume und redigiere sensible Werte vor dem Einsatz.

FAQ

Brauche ich einen lokalen PostHog-Server? Nein. Der normale Zugang ist gehostet. mcp-remote ist nur eine lokale stdio-Brücke; der lokale Hono- und Redis-Stack ist für die Entwicklung des offiziellen Quellprojekts dokumentiert.

Kann ein Agent ein Flag ausrollen? Technisch können dokumentierte Flag- und Experimentwerkzeuge schreiben. Nutze eine Tool-Allowlist und verlange vor jedem Rollout eine explizite menschliche Bestätigung von Projekt, Regel, Zielgruppe und Wirkung.

Bleiben Daten automatisch beim MCP-Server? PostHog sagt, der MCP-Server speichere Analytics-Daten nicht und proxyte Abfragen zum Projekt. Tool-Ergebnisse können jedoch im Client- und Modellpfad verarbeitet werden; diese Richtlinien müssen separat geprüft werden.