Línea de comandos y MCP en app builders: qué cambia cuando el proyecto sale del navegador
La mayoría de las herramientas de construcción con IA vive entera dentro de una pestaña. Eso resuelve muy bien el principio, y empieza a apretar cuando el proyecto crece: quieres ejecutar la app en tu máquina, abrir los archivos en el editor que ya usas, pedir un cambio al asistente que ya está abierto en tu terminal.
Ahí entran dos piezas que cambian bastante el día a día, y que hoy separan a las plataformas: una línea de comandos de verdad y un servidor MCP.
Lo que resuelve una línea de comandos y el navegador no
Tres cosas concretas.
Ver el proyecto entero de una vez. En pantalla, la definición de la app aparece repartida en pestañas:
entidades aquí, automatizaciones allá, la configuración de cada página en otro sitio. En disco, es una carpeta.
Abres fab.schema.json y lees todas las entidades y campos en una sola pantalla, y la búsqueda de tu editor
funciona encima de eso.
Ejecutar antes de publicar. Un comando que levanta la app en tu máquina, sobre la misma plantilla con la que la plataforma publica, da el ciclo corto que falta cuando cada comprobación depende de un despliegue.
Automatizar. En cuanto la definición es un archivo, entra en control de versiones, en revisión por pull request y en una tubería de CI. Eso no le interesa a todo el mundo, y a quien entrega apps a clientes le interesa mucho.
Lo que resuelve un servidor MCP
MCP es el protocolo que deja a un asistente hablar con una herramienta sin intermediario humano. En la práctica, es la diferencia entre estos dos diálogos:
"Pega aquí el esquema de tu proyecto para que pueda sugerir la automatización."
"Voy a leer el esquema y escribir la automatización."
El segundo es lo que pasa cuando hay un servidor MCP corriendo con tu credencial. El asistente llama a la operación de lectura, recibe las entidades reales, los campos reales y los ids reales, y escribe encima de eso.
Y esta es la parte que se suele subestimar: sin el esquema a mano, un modelo inventa. Un id de modelo equivocado responde 404, un campo que no existe responde 422, y el asistente gasta tres intentos corrigiendo argumentos cuando el problema era no haber leído nada antes de escribir.
El detalle que decide la seguridad: cómo nace la clave
Casi toda plataforma que ofrece acceso por terminal resuelve la autenticación igual: una pantalla con un botón "generar clave", un valor que aparece una vez, y un aviso para guardarlo en un lugar seguro.
El problema no es la clave, es su trayecto. Entre esa pantalla y tu terminal pasa por el portapapeles, casi siempre por el historial del shell, a veces por un canal de chat cuando alguien tiene que configurar la máquina de otra persona, y con frecuencia por un archivo de configuración que termina en un repositorio.
La alternativa es el flujo de dispositivo, el mismo patrón que ya usaste para autorizar una aplicación en un televisor. La terminal pide una autorización, muestra un código corto y abre una página donde compruebas que el código coincide y apruebas. La clave nace dentro de la máquina que va a usarla y nunca se muestra en ningún sitio.
Tres consecuencias valen la pena:
- Nada que copiar significa nada que filtrar. La clave no existe en forma visible en ningún momento.
- El permiso se pide en el momento. Una máquina que solo necesita consultar pide lectura, y su credencial ni siquiera ve las operaciones de escritura. Un asistente que no ve una herramienta no la intenta y no gasta rondas leyendo un 403 como un error de argumento.
- La revocación está del lado correcto. Cerrar sesión en una máquina olvida la credencial allí. Revocar en el panel tumba esa máquina en el servidor, que es lo que necesitas cuando el portátil ya no está.
Dónde queda la credencial después
En el llavero del sistema operativo, cuando lo hay. Cuando no lo hay, en un archivo con permisos restringidos, y conviene exigir que la herramienta diga que cayó en ese caso. Una herramienta que elige el peor lugar en silencio enseña al usuario a suponer que siempre está en el mejor.
Lo que se queda fuera de la terminal, a propósito
Dos cosas, y la división es deliberada:
Credenciales de integración. Los archivos que describen lo que el proyecto tiene conectado deben ser de solo lectura: dicen que la integración existe y qué operaciones llamar, para que un asistente pueda trabajar, y nunca el secreto en sí. Conectar y rotar ocurre en la plataforma.
Borrar. Un archivo que desapareció de tu carpeta no debería desaparecer de la app. Tu copia local puede estar desactualizada, la IA puede haber editado el proyecto en la plataforma mientras tanto, y borrar allí por una ausencia aquí destruye trabajo. El comportamiento correcto es informar de la diferencia y dejarte la decisión.
Cómo evaluar esto en una plataforma
Si estás comparando herramientas y este tipo de acceso importa, cinco preguntas las separan rápido:
- ¿La clave se copia o nace por flujo de dispositivo?
- ¿Se puede pedir solo lectura?
- ¿La revocación vale para el servidor o solo olvida la clave en la máquina?
- ¿El servidor MCP expone lectura de esquema, o solo operaciones de escritura?
- ¿Qué hace el comando de publicación con un archivo que desapareció?
Las respuestas dicen más sobre la madurez de la herramienta que la lista de comandos.
En Fabapp
La línea de comandos hace login por flujo de dispositivo, guarda la credencial en el llavero, acepta
--scopes "read" para una máquina que solo consulta, y trae la definición del proyecto con pull. dev ejecuta la
app localmente sobre la misma plantilla de la publicación, y deploy publica. El servidor MCP usa la credencial que
el login ya guardó y respeta su permiso: un token de lectura no lista las herramientas de escritura.
Las máquinas conectadas están en Perfil, en Claves y CLI, con el permiso de cada una y su último uso. La revocación es inmediata y vale para el servidor.