Saltar al contenido principal

Construir con tu agente (MCP)

Este es el flujo de trabajo principal: el panel se construye en tu propio agente — Claude Code, Codex, Cursor, cualquier cliente MCP — y todo aquello de lo que depende se mantiene en Vibedasher. No construyes dentro de nuestra aplicación. Tu agente trabaja en local, y el servidor vibedasher-mcp le da herramientas sobre la plataforma mantenida — conjuntos de datos, el motor de consultas, borradores y builds de paneles, publicación, compartición, derechos de acceso — de modo que la mitad con estado (conexiones, conjuntos de datos, pipelines, actualizaciones, gobernanza, hosting) se queda donde se mantiene y se gobierna, mientras el código del panel se queda en manos de tu agente.

Conviene saber esto antes de escribir una sola línea

Lo que se aloja es un bundle renderizado en el cliente. Tu panel es React que corre en el navegador del visitante sobre datos servidos por SQL. Nada de tu código de servidor se ejecuta aquí — ni rutas de API, ni renderizado en servidor, ni loaders, ni workers en segundo plano — de modo que un framework con renderizado en servidor no puede alojarse tal cual: Next.js con cualquiera de sus dos routers, Remix, SvelteKit, Astro, Nuxt. Tampoco hay npm install en tiempo de build; las librerías vienen de una lista fijada, y React es el único framework que está en ella.

Esa pila no se rechaza, se encamina. Dos puertas, las dos abiertas: quédate con tu propio servidor y lleva a él los datos de esta cuenta con el SDK que la instalación ya te dio, o construye el panel aquí y expúlsalo para alojarlo tú mismo. En cualquiera de los dos casos las conexiones, los conjuntos de datos, las actualizaciones, la gobernanza y el motor de consultas siguen mantenidos de este lado.

¿Ya tienes un árbol? check_viz_tree(src_dir=<absolute path>) responde a esto de forma estática, contra tus archivos reales, antes de gastar un build.

Instala e inicia sesión​

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

vibedasher login abre tu navegador, apruebas la sesión y ya está. El refresh token se escribe en el keyring de tu sistema operativo — o, en una máquina sin backend de keyring, en un archivo 0600 bajo ~/.vibedasher/. Ninguna clave que generar, copiar en un archivo de configuración o rotar. El subcomando login necesita 0.6.0 o posterior; las versiones anteriores no lo tienen.

Solo hay dos subcomandos más:

vibedasher whoami    # la cuenta, usuario y región con sesión iniciada, y cuándo toca re-consentir
vibedasher logout    # revoca la sesión de esta máquina y la olvida

Por defecto login inicia sesión en eu-central-1; pasa --region para otra región, y --timeout para cambiar cuánto espera el callback (180 s).

Si tu terminal no tiene un navegador que pueda abrir — WSL, una sesión de escritorio sin X, una terminal sin manejador por defecto — usa vibedasher login --no-browser. Imprime la URL en lugar de abrirla, y espera el mismo callback. Ten en cuenta que el listener del callback se enlaza a 127.0.0.1 en un puerto que el sistema operativo elige al conectar, así que el navegador en el que pegas la URL tiene que estar en la misma máquina. Iniciar sesión desde un portátil para una máquina remota no es un carril que login soporte — para una máquina a la que solo llegas por SSH, usa una clave de API (más abajo).

Luego registra el servidor. Con Claude Code:

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

O en cualquier configuración de cliente MCP:

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

Nota que vibedasher-mcp es el punto de entrada del servidor que lanza tu cliente MCP; vibedasher es el CLI que ejecutas tú mismo. El servidor recoge la sesión que vibedasher login guardó — no hay ninguna credencial en el bloque de configuración.

El servidor solo habla con la API pública y medida — la misma superficie que los SDKs. Nada por un canal lateral, y ninguna credencial se refleja jamás en los resultados de las herramientas.

Sin interfaz y CI — usa una clave de API​

Un runner de build, una máquina de cron, un contenedor: ningún sitio donde abrir un navegador, y nadie que haga clic en aprobar. Ahí, autentícate con una clave de API en su lugar. Genera una desde la aplicación en cloud.vibedasher.com (Ajustes → Claves de API) — la creación de claves es exclusivamente de sesión, así que es una acción de navegador, no una llamada a la API; mira Autenticación — y ponla en el bloque env del servidor:

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

VIBEDASHER_API_KEY tiene prioridad cuando está definida: el servidor usa la clave e ignora cualquier sesión de inicio guardada. Trata la clave como una contraseña — una variable de entorno o un gestor de secretos, nunca el control de versiones. En tu propia máquina, prefiere vibedasher login; así no queda ningún secreto de larga duración en disco que pueda filtrarse o necesitar rotación.

El ciclo que ejecuta tu agente​

Todo lo que sigue es tu agente construyendo el panel — el estado de la plataforma contra el que construye (conexiones, conjuntos de datos, actualizaciones, gobernanza) se configura una vez y se mantiene en Vibedasher, así que cada iteración del ciclo lo encuentra ya disponible.

  1. Introduce los datos — upload_dataset_from_file(name, csv_path) para un archivo en disco (upload_dataset toma el CSV en línea en su lugar, lo que cuesta tokens por cada fila), o create_dataset_from_connection contra una fuente de datos conectada. Cada conjunto de datos obtiene un alias cleanSQLName — ese alias es el nombre de la tabla en SQL, nunca el nombre de una tabla física.
  2. Explora — run_query(sql, dataset_ids): un SELECT de solo lectura a través de conjuntos de datos, con columnas y filas tipadas de vuelta.
  3. Crea y construye — create_viz(name, dataset_ids), luego push_viz_files(viz_id, files) con un App.tsx en la raíz, luego build_viz → get_build_status(build_id) hasta que el paquete compile. ¿Ya tienes un árbol React? check_viz_tree(src_dir=...) nombra primero cada cambio que necesita, de forma estática, sin gastar un build.
  4. Publica — publish_viz(viz_id) promueve el borrador a la versión que ven los visores, y share_viz(viz_id) devuelve el enlace para compartir. build_viz por sí solo no publica.
  5. Verifica — render_probe(viz_id) abre el panel publicado en un navegador real e informa de lo que realmente se pintó: cuántos mosaicos se renderizaron, las cifras principales releídas literalmente, y cualquier error de consola. Un build en verde significa que el código compiló — no que el gráfico muestra lo que su título dice, y un gráfico que nunca recibió datos deja un lienzo de un solo color a tamaño completo que toda comprobación basada en conteos aprueba.
  6. Itera — eject_viz para extraer el código React completo, editarlo en local, push_viz_files para confirmar los cambios de vuelta a la rama del borrador, reconstruir, volver a publicar.

Tu agente también tiene herramientas para carpetas, grupos, usuarios y derechos de acceso (grant_access / revoke_access), así que la gobernanza también es programable — mira Publicar y compartir.

Expulsar — el código sigue siendo tuyo​

Publicar en Vibedasher es el final normal del ciclo — eso es lo que mantiene el panel alojado, gobernado y conectado a datos mantenidos. Pero el código en sí es React y SQL sencillos y sigue siendo tuyo: eject_viz le entrega a tu agente el árbol de código fuente completo y ejecutable (componentes, package.json, configuración de Tailwind) más un manifiesto de conexión, y eject_instructions explica cómo reconstruirlo de forma nativa en tu propia aplicación — consultas que corren a través del SDK contra tus conjuntos de datos de Vibedasher, con hosting enteramente de tu lado. Los árboles grandes se entregan a disco (out_dir=...) o paginados; sigue delivery.pendingPaths hasta que esté vacío antes de tratar el árbol como completo.

Una elección dentro de eso vale la pena tomarla a propósito, porque es la mitad que ya no puedes cambiar después. Un panel expulsado desde una visualización pública y publicada viene con un carril sin credenciales: descarga un extracto Parquet y ejecuta cada consulta en el navegador del visitante, sin clave, sin token y sin backend propio. Eso también significa que cada visitante obtiene todas las filas del conjunto de datos, y que a ningún visor se le pueden mostrar menos filas que a otro — mira Quién puede ver qué para los dos montajes que sí pueden acotar a un visor, y decide entre ellos antes de construir.

La historia completa — las tres llamadas de expulsión, el contrato de paginación, y las dos generaciones de props que siguen vivas — está en Expulsa tu panel.

Siguiente​

La aplicación en cloud.vibedasher.com trabaja sobre los mismos paneles y borradores que tu agente, así que una persona puede revisar en la interfaz y publicar desde ahí — pero el ciclo del agente de arriba es la vía para la que construimos y que documentamos.