Aclif propone un CLI con una sola gramática para que los agentes hablen con cualquier SaaS
El framework, publicado en npm como @aclif/core, carga la definición de cada comando solo cuando el agente la pide, de modo que toda la API del proveedor queda accesible sin ocupar contexto en cada turno.
Aclif es un CLI para que los agentes de IA operen contra cualquier SaaS con una sola gramática. Se instala con npm install -g @aclif/core y el agente descubre, aprende e interroga los comandos sin más documentación que el propio binario. El código está en el repositorio y el contrato con sus esquemas JSON, en CONTRACT.md.
El punto de partida es el coste de contexto. Un servidor MCP publica una lista fija de herramientas y cada una de ellas ocupa contexto en todos los turnos, así que su autor decide al construirlo cuánto cubre: publicar todas las operaciones —una API típica tiene cientos— mantiene todo accesible y quema tokens sin parar; publicar cuatro operaciones amplias ahorra contexto y deja fuera todo lo que no eligió. Aclif carga la definición de un comando solo cuando el agente lo pide, de modo que la API entera sigue siendo alcanzable sin coste fijo.
Una gramática y nombres canónicos
La herramienta impone una única estructura de comando, un único envelope JSON y un único vocabulario de errores para todos los proveedores. Los alias traducen los nombres locales: customer apunta a Account en una instancia de Salesforce y a core_company en ServiceNow, y el mismo registro responde al mismo nombre en cualquier plataforma. Un catálogo de inquilino, capturado de cada instancia en el momento del despliegue, enseña a la CLI los objetos y campos personalizados sin tocar el proveedor.
Los errores están pensados para resolverse en un turno: cada uno nombra el fallo, el comando que lo arregla y, si el clasificador tiene una regla de reescritura para ese error, la entrada corregida lista para reenviar. Ese clasificador es código, no un modelo detrás.
Introspección sin ejecución
Los flags --schema, --examples, --shape y otros cuatro devuelven antes de que el comando se ejecute, no piden credenciales y no consumen cuota de API. Un agente puede explorar una instancia limitada por tasa sin gastar nada. Los códigos de salida son 0, 1 para errores de API, 2 para uso y 3 para autenticación.
Cada comando declara mutabilidad, radio de impacto, reversibilidad e idempotencia, y una comprobación de política puede rechazarlo antes de que cargue su código. Toda mutación acepta --dry-run, exige --confirm cuando su metadata lo indica y escribe una línea de auditoría después de cada ejecución.
Las clases de comando corren igual en tres sitios: lanzadas por el propio agente, embebidas en una aplicación anfitriona que guarda las credenciales y ejecuta en proceso, o dentro de un flujo definido en el que el comando se fija en tiempo de diseño y la autoridad para ejecutarlo —credencial, identidad, política— se aporta en tiempo de ejecución. Ese tercer caso saca la inferencia de la llamada por completo.
El argumento se sostiene sobre el diseño, no sobre números: la presentación no incluye ninguna medición de tokens ni de latencia frente a un servidor MCP equivalente, y tampoco una comparativa con los CLI propios de cada proveedor. Ahí está lo que falta, porque el ahorro de contexto es justo lo que habría que medir.
