QA Step by Step

MCP vs CLI: en tus pruebas automatizadas

Si también estás automatizando pruebas con agentes de IA y te preguntas cuándo usar un MCP y cuándo el CLI, te dejo este resumen.

Un equipo conectó un agente de IA a su infraestructura de testing. La idea era simple: que el agente ejecutara suites de pruebas automáticas contra un entorno de staging de pagos. El agente tenía acceso a la terminal. Podía correr pytest, curl, lo que fuera. El resultado: el agente, en su intento de ser "útil", ejecutó un DROP en una base de datos de prueba que compartían tres equipos. No era producción. Pero se perdieron dos días de trabajo. Esto es un ejemplo de lo que pasa cuando le das a un agente de IA acceso sin restricciones a una CLI y le dices "corre las pruebas".

Hoy quiero hablar de lo mínimo a tomar en cuenta al momento de automatizar pruebas con agentes de IA: la diferencia entre conectar agentes de IA vía CLI y vía MCP, cuándo usar cada uno, y cómo diseñar una estrategia que no termine en desastre.

Las 4 diferencias que importan

¿Cómo interactúa el agente?

Con CLI, el agente está haciendo prueba y error. Escribe un comando, lee texto libre que puede ser un error criptico, un warning largo, o un output con formato raro, interpreta, y decide el siguiente paso. Funciona, pero es frágil. Cualquiera que haya debugueado por qué grep no encontró algo que claramente estaba ahí sabe de lo que hablo.

Con MCP, el agente lee un esquema JSON que le dice exactamente: "esta función acepta estos parámetros y devuelve este formato". No hay ambigüedad. No hay que parsear texto libre.

En QA esto es crítico. Cuando un agente ejecuta pruebas contra un sistema de pagos, quiere saber exactamente qué hizo y qué respuesta recibió. No quieres que el agente "interprete" que un timeout fue un éxito porque el output no contenía la palabra "error".

Seguridad y gobernanza

CLI opera con permisos a nivel de sistema operativo. Si el agente tiene acceso a una terminal con credenciales de AWS, puede hacer todo lo que esas credenciales permitan. Listar buckets, borrar objetos, crear instancias. El agente no distingue entre "lo que debería hacer" y "lo que puede hacer".

MCP define funciones específicas con permisos explícitos. Si diseñes un servidor MCP para tu entorno de testing de pagos, puedes exponer simulate_card_payment() sin darle acceso a delete_all_transactions() o a la base de datos directamente. Cada llamada queda registrada con sus parámetros y respuesta. Tienes un audit trail completo.

Costo en tokens

Esto casi nadie lo menciona. CLI parece barata: mandas un comando corto, recibes un output. Pero ese output muchas veces es texto largo, desordenado, con warnings, con formato para humanos. El agente necesita procesarlo, interpretarlo y razonar sobre él. Eso consume tokens de razonamiento, que son los más caros.

MCP tiene lo que llama el "impuesto de contexto": los esquemas de las herramientas se cargan en el contexto del agente y consumen tokens antes de que haga nada. Pero la ejecución es más determinista. El agente no necesita reinterpretar outputs ambiguos. Gasta menos en razonamiento.

Para tareas simples y puntuales, CLI es más eficiente. Para flujos complejos con múltiples pasos en fintech (crear usuario de prueba, simular pago, verificar webhook, validar estado en base de datos), MCP sale más barato a escala.

Escalabilidad

CLI requiere que cada entorno tenga las herramientas instaladas, con las versiones correctas. Cuando actualizas algo, lo actualizas en cada máquina, en cada pipeline, en cada contenedor. Y a veces rompe silenciosamente: ese tipo de falla donde todo dice "OK" pero los resultados están mal.

MCP centraliza. Actualizas el servidor; todos los agentes que se conectan reciben los cambios. Los esquemas están versionados. Para equipos de QA que manejan múltiples entornos (staging, sandbox del procesador, entorno de certificación del banco), esto cambia las reglas del juego.

Paso a paso: cómo implementar tu primera estrategia de pruebas con agentes

1. Mapea tus casos de uso de automatización: Antes de elegir herramientas, entiende qué necesitas automatizar. En fintech/QA los casos típicos caen en tres categorías: ejecución de suites de pruebas, gestión de entornos e interacciones con sistemas financieros. Cada categoría tiene un perfil de riesgo diferente. Correr pytest en un entorno aislado no es lo mismo que simular un pago contra la API sandbox de un procesador.
2. Diseña interfaces CLI deterministas: Para los casos de bajo riesgo, CLI funciona bien. Pero no le des al agente acceso directo a bash. Crea wrappers con salida en JSON o formato estructurado. Esto reduce el costo de interpretación del agente y los errores de parsing.
3. Diseña herramientas MCP como contratos de QA: Para los casos sensibles (pagos, KYC, datos financieros), cada herramienta MCP debe tener inputs tipados, outputs predecibles y no exponer más de lo necesario. El agente no puede inventar parámetros que no existen ni ejecutar acciones que no están definidas.
4. Testea a tus agentes. Contract tests para MCP: verifican que las herramientas responden con el esquema correcto y rechazan inputs inválidos. Robustness tests para CLI: simula outputs inesperados, timeouts, y prompts interactivos. Esto es QA sobre QA. Meta, pero necesario.
5. Crea una matriz de permisos explícita: la regla de oro: si la acción toca datos financieros, aunque sean de prueba, pasa por MCP con audit trail. Punto.
6. Monta observabilidad centralizada: Necesitas ver qué están haciendo tus agentes en tiempo real. Logs de cada llamada MCP con parámetros, respuesta y latencia. Logs de cada comando CLI con su output. Alertas cuando un agente falla repetidamente o intenta una acción no autorizada. Sin observabilidad estas volando a ciegas, y en fintech eso tiene consecuencias regulatorias.
7. Adopta el enfoque híbrido: en la práctica casi nunca es "solo CLI" o "solo MCP". Lo que funciona: envuelve tus CLIs detrás de MCP. El agente nunca llama a bash directamente. En cambio llama una herramienta MCP que internamente ejecuta el comando CLI, captura el output, lo estructura, y lo devuelve limpio. Flexibilidad de CLI con gobernanza de MCP.

La pregunta no es si vas a usar agentes de IA en tu infraestructura de QA. Eso ya está pasando. La pregunta es si les vas a dar acceso controlado o acceso libre.

Cada vez estoy más convencida de que MCP (o algo con esa filosofía de interfaces controladas) va a ser el estándar para cualquier sistema donde los errores cuestan dinero.

No porque CLI sea malo. CLI es increíblemente poderosa y va a seguir siendo útil para un montón de cosas. Pero darle bash a un agente de IA sin restricciones es apostar a que nunca va a cometer errores.

El futuro son agentes con interfaces diseñadas para agentes. Y los equipos que empiecen a construir esas interfaces hoy van a tener una ventaja enorme mañana.