Zum Hauptinhalt springen

Mit Ihrem Agenten bauen (MCP)

Das ist der zentrale Arbeitsablauf: Das Dashboard wird in Ihrem eigenen Harness gebaut — Claude Code, Codex, Cursor, jeder MCP-Client — und alles, wovon es abhängt, wird bei Vibedasher betrieben. Sie bauen nicht innerhalb unserer App. Ihr Agent arbeitet lokal, und der vibedasher-mcp-Server gibt ihm Werkzeuge für die betriebene Plattform — Datensätze, die Query-Engine, Dashboard-Entwürfe und -Builds, Veröffentlichung, Teilen, Zugriffsrechte — sodass die zustandsbehaftete Hälfte (Verbindungen, Datensätze, Pipelines, Aktualisierungen, Governance, Hosting) dort bleibt, wo sie betreut und verwaltet wird, während der Dashboard-Code in der Hand Ihres Agenten bleibt.

Das sollten Sie wissen, bevor Sie eine Zeile davon schreiben

Was gehostet wird, ist ein clientseitig gerendertes Bundle. Ihr Dashboard ist React, das im Browser des Besuchers über per SQL bereitgestellte Daten läuft. Nichts von Ihrem Servercode wird hier ausgeführt — keine API-Routen, kein serverseitiges Rendering, keine Loader, keine Hintergrund-Worker — ein serverseitig gerendertes Framework kann daher so, wie es ist, nicht gehostet werden: Next.js mit beiden Routern, Remix, SvelteKit, Astro, Nuxt. Es gibt zur Build-Zeit auch kein npm install; Bibliotheken kommen aus einer festgelegten Liste, und React ist das einzige Framework darauf.

Dieser Stack wird nicht abgelehnt, er wird umgeleitet. Zwei Türen, beide offen: Behalten Sie Ihren eigenen Server und holen Sie die Daten dieses Kontos mit dem SDK dorthin, das die Installation Ihnen schon mitgegeben hat, oder bauen Sie das Dashboard hier und werfen Sie es aus, um es selbst zu hosten. In beiden Fällen bleiben die Verbindungen, Datensätze, Aktualisierungen, Governance und die Query-Engine auf dieser Seite betreut.

Sie haben schon einen Baum? check_viz_tree(src_dir=<absolute path>) beantwortet das statisch, gegen Ihre echten Dateien, bevor Sie einen Build verbrauchen.

Installieren und anmelden​

pip install 'vibedasher-mcp>=0.6.0'
vibedasher login

vibedasher login öffnet Ihren Browser, Sie bestätigen die Sitzung, und Sie sind fertig. Der Refresh-Token wird in Ihrem Betriebssystem-Schlüsselbund gespeichert — oder, auf einer Maschine ohne Schlüsselbund-Backend, in einer 0600-Datei unter ~/.vibedasher/. Kein Schlüssel zum Erzeugen, in eine Konfigurationsdatei zu kopieren oder zu rotieren. Der Unterbefehl login benötigt Version 0.6.0 oder höher; frühere Releases haben ihn nicht.

Zwei weitere Unterbefehle gibt es sonst nicht:

vibedasher whoami    # das angemeldete Konto, den Benutzer und die Region sowie wann die erneute Zustimmung fällig ist
vibedasher logout    # die Sitzung dieser Maschine widerrufen und vergessen

Standardmäßig meldet login Sie bei eu-central-1 an; übergeben Sie --region für eine andere Region und --timeout, um zu ändern, wie lange auf den Callback gewartet wird (180 s).

Wenn Ihr Terminal keinen Browser öffnen kann — WSL, eine X-lose Desktop-Sitzung, ein Terminal ohne Standard-Handler —, verwenden Sie vibedasher login --no-browser. Es gibt die URL aus, statt sie zu öffnen, und wartet auf denselben Callback. Beachten Sie, dass der Callback-Listener 127.0.0.1 auf einem Port bindet, den das Betriebssystem beim Verbinden wählt, sodass der Browser, in den Sie die URL einfügen, auf derselben Maschine laufen muss. Sich von einem Laptop aus für eine entfernte Maschine anzumelden, ist kein Weg, den login unterstützt — für eine Maschine, die Sie nur über SSH erreichen, verwenden Sie einen API-Schlüssel (unten).

Registrieren Sie dann den Server. Mit Claude Code:

claude mcp add vibedasher --env VIBEDASHER_REGION=eu-central-1 -- vibedasher-mcp

Oder in jeder MCP-Client-Konfiguration:

{
  "mcpServers": {
    "vibedasher": {
      "command": "vibedasher-mcp",
      "env": { "VIBEDASHER_REGION": "eu-central-1" }
    }
  }
}

Beachten Sie: vibedasher-mcp ist der Server-Einstiegspunkt, den Ihr MCP-Client startet; vibedasher ist die CLI, die Sie selbst ausführen. Der Server übernimmt die Sitzung, die vibedasher login gespeichert hat — es gibt kein Zugangsdatum im Konfigurationsblock.

Der Server spricht nur mit der öffentlichen, gemessenen API — derselben Oberfläche wie die SDKs. Nichts über einen Seitenkanal, und kein Zugangsdatum wird jemals in Werkzeugergebnissen zurückgegeben.

Headless und CI — einen API-Schlüssel verwenden​

Ein Build-Runner, eine Cron-Maschine, ein Container: kein Ort, an dem ein Browser sich öffnen könnte, und niemand, der auf „Zustimmen" klicken kann. Dort authentifizieren Sie sich stattdessen mit einem API-Schlüssel. Erzeugen Sie einen in der App unter cloud.vibedasher.com (Einstellungen → API-Schlüssel) — die Schlüsselerstellung ist bewusst nur per Sitzung möglich, also eine Browser-Aktion, kein API-Aufruf; siehe Authentifizierung — und legen Sie ihn in den env-Block des Servers:

{
  "mcpServers": {
    "vibedasher": {
      "command": "vibedasher-mcp",
      "env": {
        "VIBEDASHER_API_KEY": "<your-api-key>",
        "VIBEDASHER_REGION": "eu-central-1"
      }
    }
  }
}

VIBEDASHER_API_KEY hat Vorrang, wenn es gesetzt ist: Der Server verwendet den Schlüssel und ignoriert jede gespeicherte Login-Sitzung. Behandeln Sie den Schlüssel wie ein Passwort — eine Umgebungsvariable oder einen Secret-Store, niemals die Versionskontrolle. Auf Ihrer eigenen Maschine bevorzugen Sie vibedasher login; dann liegt kein langlebiges Geheimnis auf der Festplatte, das durchsickern oder rotiert werden müsste.

Der Kreislauf, den Ihr Agent durchläuft​

Alles Folgende ist Ihr Agent, der das Dashboard baut — der Plattformzustand, gegen den er baut (Verbindungen, Datensätze, Aktualisierungen, Governance), wird einmal eingerichtet und bei Vibedasher betrieben, sodass jeder Durchlauf des Kreislaufs ihn bereits vorfindet.

  1. Daten hereinholen — upload_dataset_from_file(name, csv_path) für eine Datei auf der Festplatte (upload_dataset nimmt das CSV stattdessen inline, was für jede Zeile Tokens kostet), oder create_dataset_from_connection gegen eine verbundene Datenquelle. Jeder Datensatz erhält einen cleanSQLName-Alias — dieser Alias ist der Tabellenname in SQL, niemals ein physischer Tabellenname.
  2. Erkunden — run_query(sql, dataset_ids): schreibgeschützte SELECT-Abfragen über Datensätze hinweg, typisierte Spalten und Zeilen zurück.
  3. Erstellen & bauen — create_viz(name, dataset_ids), dann push_viz_files(viz_id, files) mit einer App.tsx im Wurzelverzeichnis, dann build_viz → get_build_status(build_id), bis das Bundle kompiliert. Sie haben schon einen React-Baum? check_viz_tree(src_dir=...) nennt zuerst jede nötige Änderung, statisch, ohne einen Build zu verbrauchen.
  4. Veröffentlichen — publish_viz(viz_id) befördert den Entwurf zu der Version, die Betrachter sehen, und share_viz(viz_id) liefert den Link zum Weitergeben. build_viz allein veröffentlicht nicht.
  5. Verifizieren — render_probe(viz_id) öffnet das veröffentlichte Dashboard in einem echten Browser und berichtet, was tatsächlich gezeichnet wurde: wie viele Kacheln gerendert wurden, die Kennzahlen wörtlich zurückgelesen, und jeden Konsolenfehler. Ein grüner Build bedeutet, dass der Code kompiliert hat — nicht, dass das Diagramm zeigt, was sein Titel behauptet, und ein Diagramm, das nie Daten erhalten hat, hinterlässt eine formatfüllende einfarbige Fläche, bei der jede zählbasierte Prüfung durchgeht.
  6. Iterieren — eject_viz, um den vollständigen React-Quellcode zu holen, lokal zu bearbeiten, push_viz_files, um zurück in den Entwurfs-Branch zu committen, neu zu bauen und erneut zu veröffentlichen.

Ihr Agent verfügt auch über Werkzeuge für Ordner, Gruppen, Benutzer und Zugriffsrechte (grant_access / revoke_access), sodass Governance ebenfalls skriptfähig ist — siehe Veröffentlichen und teilen.

Auswerfen — der Code bleibt Ihrer​

Die Veröffentlichung bei Vibedasher ist der normale Abschluss des Kreislaufs — das ist es, was das Dashboard gehostet, verwaltet und an betreute Daten angebunden hält. Aber der Code selbst ist reines React und SQL und bleibt Ihrer: eject_viz übergibt Ihrem Agenten den vollständigen lauffähigen Quellbaum (Komponenten, package.json, Tailwind-Konfiguration) sowie ein Verdrahtungsmanifest, und eject_instructions erklärt, wie man ihn nativ in Ihrer eigenen App neu aufbaut — Abfragen laufen über das SDK gegen Ihre Vibedasher-Datensätze, Hosting vollständig auf Ihrer Seite. Große Bäume werden auf die Festplatte geliefert (out_dir=...) oder seitenweise; folgen Sie delivery.pendingPaths, bis es leer ist, bevor Sie den Baum als vollständig betrachten.

Eine Entscheidung darin sollten Sie bewusst treffen, denn sie ist die Hälfte, die Sie nachträglich nicht mehr ändern können. Ein Dashboard, das aus einer öffentlichen und veröffentlichten Visualisierung ausgeworfen wurde, bringt eine Spur ohne Zugangsdaten mit: Es lädt einen Parquet-Auszug herunter und führt jede Abfrage im Browser des Besuchers aus — ohne Schlüssel, ohne Token und ohne eigenes Backend. Das heißt auch, dass jeder Besucher jede Zeile des Datensatzes erhält und keinem Betrachter weniger Zeilen gezeigt werden können als einem anderen — siehe Wer sieht was für die beiden Verdrahtungen, die einen Betrachter einschränken können, und entscheiden Sie sich zwischen ihnen, bevor Sie bauen.

Die vollständige Geschichte — die drei Eject-Aufrufe, der Paging-Vertrag und die zwei aktiven Prop-Generationen — steht in Ihr Dashboard auswerfen.

Als Nächstes​

Die App unter cloud.vibedasher.com arbeitet mit denselben Dashboards und Entwürfen wie Ihr Agent, sodass ein Mensch in der Benutzeroberfläche prüfen und von dort veröffentlichen kann — aber der oben beschriebene Harness-Kreislauf ist der Weg, für den wir entwickeln und den wir dokumentieren.