Aller au contenu principal

Construire avec votre agent (MCP)

C'est le flux de travail central : le tableau de bord est construit dans votre propre harness — Claude Code, Codex, Cursor, tout client MCP — et tout ce dont il dépend est maintenu dans Vibedasher. Vous ne construisez pas dans notre application. Votre agent travaille en local, et le serveur vibedasher-mcp lui donne des outils vers la plateforme maintenue — jeux de données, moteur de requêtes, brouillons et builds de tableaux de bord, publication, partage, droits d'accès — de sorte que la moitié à état (connexions, jeux de données, pipelines, actualisations, gouvernance, hébergement) reste là où elle est maintenue et gouvernée, tandis que le code du tableau de bord reste entre les mains de votre agent.

À savoir avant d'en écrire une seule ligne

Ce qui est hébergé est un bundle rendu côté client. Votre tableau de bord est du React qui tourne dans le navigateur du visiteur sur des données servies par SQL. Aucune ligne de votre code serveur ne s'exécute ici — pas de routes d'API, pas de rendu côté serveur, pas de loaders, pas de workers d'arrière-plan — de sorte qu'un framework à rendu serveur ne peut pas être hébergé tel quel : Next.js sur l'un ou l'autre routeur, Remix, SvelteKit, Astro, Nuxt. Il n'y a pas non plus de npm install au moment du build ; les bibliothèques viennent d'une liste épinglée, et React est le seul framework qui y figure.

Cette pile n'est pas refusée, elle est orientée. Deux portes, toutes deux ouvertes : gardez votre propre serveur et tirez-y les données de ce compte avec le SDK que l'installation vous a déjà donné, ou construisez le tableau de bord ici et éjectez-le pour l'héberger vous-même. Dans les deux cas, les connexions, les jeux de données, les actualisations, la gouvernance et le moteur de requêtes restent maintenus de notre côté.

Vous avez déjà un arbre ? check_viz_tree(src_dir=<absolute path>) y répond statiquement, contre vos vrais fichiers, avant de dépenser un build.

Installer et se connecter​

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

vibedasher login ouvre votre navigateur, vous approuvez la session, et c'est terminé. Le refresh token est écrit dans le trousseau de votre système d'exploitation — ou, sur une machine sans trousseau, dans un fichier 0600 sous ~/.vibedasher/. Aucune clé à générer, copier dans un fichier de configuration, ou faire tourner. La sous-commande login requiert la version 0.6.0 ou ultérieure ; les versions antérieures ne l'ont pas.

Deux sous-commandes supplémentaires, et c'est tout :

vibedasher whoami    # le compte connecté, l'utilisateur et la région, et quand le re-consentement est dû
vibedasher logout    # révoque la session de cette machine et l'oublie

Par défaut, login vous connecte sur eu-central-1 ; passez --region pour une autre région, et --timeout pour changer combien de temps il attend le callback (180 s).

Si votre terminal n'a pas de navigateur qu'il peut lancer — WSL, une session de bureau sans X, un terminal sans gestionnaire par défaut — utilisez vibedasher login --no-browser. Il affiche l'URL au lieu de l'ouvrir, et attend le même callback. Notez que l'écouteur de callback se lie sur 127.0.0.1 sur un port choisi par l'OS au moment de la connexion, donc le navigateur dans lequel vous collez l'URL doit être sur la même machine. Se connecter depuis un ordinateur portable pour une machine distante n'est pas une voie que login prend en charge — pour une machine à laquelle vous n'accédez que par SSH, utilisez une clé API (voir ci-dessous).

Puis enregistrez le serveur. Avec Claude Code :

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

Ou dans n'importe quelle configuration de client MCP :

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

Notez que vibedasher-mcp est le point d'entrée du serveur que votre client MCP lance ; vibedasher est la CLI que vous exécutez vous-même. Le serveur reprend la session que vibedasher login a stockée — il n'y a aucun identifiant dans le bloc de configuration.

Le serveur ne parle qu'à l'API publique et mesurée — la même surface que les SDKs. Rien en marge, et aucun identifiant n'est jamais renvoyé dans les résultats d'outils.

Headless et CI — utiliser une clé API​

Un runner de build, une machine cron, un conteneur : aucun endroit où un navigateur peut s'ouvrir, et personne pour cliquer sur approuver. Là, authentifiez-vous avec une clé API à la place. Générez-en une depuis l'application sur cloud.vibedasher.com (Paramètres → Clés API) — la création de clé se fait uniquement en session, c'est donc une action de navigateur, pas un appel d'API ; voir Authentification — et placez-la dans le bloc env du serveur :

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

VIBEDASHER_API_KEY prend le pas quand elle est définie : le serveur utilise la clé et ignore toute session de connexion stockée. Traitez la clé comme un mot de passe — une variable d'environnement ou un coffre-fort de secrets, jamais le contrôle de version. Sur votre propre machine, préférez vibedasher login ; il n'y a alors aucun secret durable sur disque susceptible de fuiter ou de nécessiter une rotation.

La boucle que votre agent exécute​

Tout ce qui suit est votre agent construisant le tableau de bord — l'état de la plateforme contre lequel il construit (connexions, jeux de données, actualisations, gouvernance) est configuré une fois et maintenu dans Vibedasher, si bien que chaque itération de la boucle le trouve déjà en place.

  1. Faire entrer des données — upload_dataset_from_file(name, csv_path) pour un fichier sur disque (upload_dataset prend le CSV en ligne à la place, ce qui coûte des tokens pour chaque ligne), ou create_dataset_from_connection contre une source de données connectée. Chaque jeu de données obtient un alias cleanSQLName — cet alias est le nom de table en SQL, jamais un nom de table physique.
  2. Explorer — run_query(sql, dataset_ids) : un SELECT en lecture seule à travers les jeux de données, avec des colonnes typées et des lignes en retour.
  3. Créer et construire — create_viz(name, dataset_ids), puis push_viz_files(viz_id, files) avec un App.tsx à la racine, puis build_viz → get_build_status(build_id) jusqu'à ce que le bundle compile. Vous avez déjà un arbre React ? check_viz_tree(src_dir=...) nomme d'abord chaque modification nécessaire, de façon statique, sans dépenser un build.
  4. Publier — publish_viz(viz_id) promeut le brouillon vers la version que voient les visionneurs, et share_viz(viz_id) renvoie le lien à diffuser. build_viz à lui seul ne publie pas.
  5. Vérifier — render_probe(viz_id) ouvre le tableau de bord publié dans un vrai navigateur et rapporte ce qui s'est réellement peint : combien de tuiles ont été rendues, les chiffres clés relus mot pour mot, et toute erreur de console. Un build vert signifie que le code a compilé — pas que le graphique montre ce que son titre prétend, et un graphique qui n'a jamais reçu de données laisse un canevas d'une seule couleur en pleine taille que toute vérification fondée sur des comptages accepte.
  6. Itérer — eject_viz pour récupérer la source React complète, l'éditer en local, push_viz_files pour valider les changements sur la branche de brouillon, reconstruire, republier.

Votre agent dispose aussi d'outils pour les dossiers, groupes, utilisateurs et droits d'accès (grant_access / revoke_access), la gouvernance est donc elle aussi scriptable — voir Publier et partager.

Éjecter — le code reste le vôtre​

Publier sur Vibedasher est la fin normale de la boucle — c'est ce qui garde le tableau de bord hébergé, gouverné et relié à des données maintenues. Mais le code lui-même est du React et du SQL ordinaires et il reste le vôtre : eject_viz remet à votre agent l'arbre source exécutable complet (composants, package.json, configuration Tailwind) plus un manifeste de câblage, et eject_instructions explique comment le reconstruire nativement dans votre propre application — les requêtes passant par le SDK contre vos jeux de données Vibedasher, l'hébergement se faisant entièrement de votre côté. Les arbres volumineux sont livrés sur disque (out_dir=...) ou paginés ; suivez delivery.pendingPaths jusqu'à ce qu'il soit vide avant de considérer l'arbre comme complet.

Un choix à l'intérieur de tout cela mérite d'être fait délibérément, car c'est la moitié que vous ne pourrez plus changer ensuite. Un tableau de bord éjecté depuis une visualisation publique et publiée embarque une voie sans identifiants : il télécharge un extrait Parquet et exécute chaque requête dans le navigateur du visiteur, sans clé, sans jeton et sans backend de votre côté. Cela signifie aussi que chaque visiteur obtient toutes les lignes du jeu de données, et qu'aucun visionneur ne peut se voir montrer moins de lignes qu'un autre — voir Qui peut voir quoi pour les deux montages qui peuvent restreindre un visionneur, et tranchez entre eux avant de construire.

L'histoire complète — les trois appels d'éjection, le contrat de pagination, et les deux générations de props encore vivantes — se trouve dans Éjecter votre tableau de bord.

Ensuite​

L'application sur cloud.vibedasher.com travaille sur les mêmes tableaux de bord et brouillons que votre agent, si bien qu'une personne peut relire dans l'interface et publier depuis là — mais la boucle du harness ci-dessus est le chemin pour lequel nous construisons et que nous documentons.