Tu agente ya puede correr código, levantar servers y publicar URLs — todo por MCP

En el post anterior explicamos el qué y el por qué: el código que genera tu IA tiene que correr en algún lado aislado, y por eso construimos sandboxes con microVMs reales. Este es el cómo.

Dos caminos, según quién lo use:

• Tu agente los usa por MCP — los llama solo, sin que escribas una línea. Si ya conectaste tu agente a Easybits, las tools de sandbox ya están ahí.
• Tú, en código, los usas con el SDK @easybits.cloud/sdk. Eso es lo que verás aquí.

1. Corre código con memoria (kernel persistente)

La diferencia entre "ejecutar un script" y "trabajar con datos" es el estado. Un agente que analiza un CSV necesita cargarlo una vez y luego hacerle diez preguntas, no recargarlo cada vez.

Por eso hay dos formas de ejecutar:

• sbx.runCode(code) — un proceso fresco por llamada (rápido para cosas sueltas). Las variables no sobreviven.
• sbx.runCell(code) — un kernel de Jupyter vivo. Las variables, los imports y los datos cargados persisten entre llamadas, igual que en un notebook.

Y lo mejor: si tu código genera una gráfica con matplotlib, te la devolvemos como imagen (PNG en base64), no como texto. Eso es lo que hace que un agente analista de datos funcione de verdad.

Es el mismo patrón que popularizó el "code interpreter" de los grandes, ahora dentro de tu Easybits.

2. Levanta un server y compártelo con una URL pública

Tu agente arma una app, una demo o un dashboard adentro del sandbox. ¿Cómo se la enseñas a alguien? Expones el puerto:

Esa URL es pública, con HTTPS válido (certificado emitido automáticamente) y vive mientras el sandbox esté encendido. El identificador del sandbox —imposible de adivinar— es la llave: solo quien tiene el link entra. Es el equivalente al getHost de E2B o al preview link de Daytona, sin que configures nada.

3. Procesos largos, sin bloquear

No todo termina en un segundo. Un build, un server de desarrollo, un scraping. Para eso está la ejecución en segundo plano:

Tu agente lanza la tarea, sigue con lo suyo, y vuelve a checar después.

4. Archivos y ciclo de vida

Dentro del sandbox tienes un sistema de archivos completo y control de vida real:

Cada microVM se auto-destruye sola al cumplir su tiempo, así que un proceso desbocado nunca se queda corriendo de a gratis.

Todo en un solo lugar (y en pesos)

El sandbox no está solo: vive junto a tu almacenamiento, tus bases de datos y tus documentos en Easybits. Con otros servicios tendrías que conectar tres proveedores distintos a mano. Aquí no: el mismo cliente, en la misma sesión, hace todo:

1. Correr código en un sandbox aislado (eb.sandboxes),
2. guardar el resultado como archivo (eb.uploadFile),
3. consultarlo después desde tu base de datos (eb.db),
4. y publicarlo en un documento o una landing (eb.createDocument).

Almacenamiento, base de datos, documentos y ejecución de código —controlados por agentes, por un solo SDK y un solo MCP—. Facturado en México, en pesos, con soporte en español.

El ejemplo completo

Y si lo tuyo es el agente: lo mismo, pero por MCP, sin escribir nada — el agente llama sandbox_create, sandbox_run_cell y sandbox_expose_port solo. Ejemplos completos (SDK, MCP y fetch) en el repo.

👉 Pruébalo en www.easybits.cloud

¿Qué le pondrías a correr a tu agente primero? Cuéntanos y lo usamos para decidir qué tool construimos después.