Dentro del arnés de evaluación MCP de Webflow

Que tu agente tenga una marca de verificación verde no significa que vaya a hacer lo correcto con tus herramientas. Solo indica que las herramientas devolvieron un JSON válido. Son cosas muy distintas, y es precisamente en esa brecha donde los servidores MCP fallan ante un usuario real, con un agente tomando sus propias decisiones. Y a veces, esas decisiones son bastante desastrosas cuando los clientes confían en que la experiencia de su marca depende de un producto. En este artículo, hablaremos sobre cómo generamos más confianza en el comportamiento de nuestro servidor MCP dentro de agentes que no controlamos.

El problema de probar un servidor MCP

El servidor del Protocolo de Contexto de Modelos (MCP) de Webflow ofrece a los agentes de IA —ya sea Claude, ChatGPT, Cursor o cualquier otra herramienta que alguien conecte— un conjunto de funciones para crear páginas, gestionar contenido en el CMS y publicar sitios en nombre del usuario. Las pruebas tradicionales pueden confirmar que cada herramienta MCP funciona bien por separado: acepta los datos correctos, aplica los permisos, modifica el estado esperado y gestiona los errores. Pero no pueden responder a otra pregunta: cuando un agente autónomo ve todo el abanico de herramientas y recibe una tarea en lenguaje sencillo, ¿sabrá descubrir y combinar esas capacidades correctamente?

La única forma de saberlo es observando cómo se comporta el agente. Y eso es exactamente lo que hace nuestro arnés de evaluación. Ejecuta agentes reales, sin interfaz gráfica, contra sitios de Webflow reales y desechables, usando tareas en lenguaje sencillo. Califica lo que el agente decide hacer, no solo si las herramientas que llamó devolvieron respuestas válidas.

Lo que hace realmente

El arnés ejecuta historias: tareas para agentes de varios pasos redactadas como instrucciones sencillas, cada una con afirmaciones sobre lo que debería suceder. Una historia podría ser "crea una colección de CMS con tres campos y una entrada" o "construye una página de aterrizaje SaaS completa sin interfaz y publícala".

Para cada historia, el arnés prepara un sitio nuevo y ejecuta un agente real paso a paso, actualmente Claude Code o el CLI Codex de OpenAI. Unas comprobaciones deterministas verifican el uso correcto o prohibido de las herramientas y, cuando es necesario, confirman que el cambio solicitado realmente se aplicó. Un juez LLM analiza la transcripción y el resultado final para evaluar si se completó la tarea, la selección de herramientas y la precisión. Las historias de construcción de páginas añaden un juez visual sobre el resultado renderizado, mientras que las señales estructurales pueden inspeccionar lo que una captura de pantalla no puede ver.

Cada rastro, puntuación, hallazgo y captura de pantalla se envía a Datadog para que las ejecuciones se puedan consultar y comparar a lo largo del tiempo. Ese es el esqueleto. Lo interesante es lo que aprendimos cuando una simple nota de aprobado o suspenso dejó de ser suficiente.

¿El agente hizo realmente lo correcto?

Separamos la precisión del resultado de los diagnósticos de la ruta de ejecución. Primero, ¿se produjo realmente el cambio de estado previsto? Segundo, ¿el agente violó alguna restricción real, como usar una herramienta destructiva o una capacidad no disponible en ese entorno? Por último, ¿tomó un camino inesperadamente difícil que sugiera que la interfaz de herramientas podría ser más clara? Un camino diferente no es necesariamente incorrecto, pero a menudo vale la pena entenderlo.

Cada ejecución deja una lista de tareas pendientes, no solo una nota

La misma llamada al juez LLM que califica una historia también genera hallazgos: problemas concretos y accionables que detectó en la transcripción, independientemente de si la historia se aprobó o no. Una llamada a una herramienta falló. El agente tuvo que sortear una capacidad confusa. Hubo que simular una capacidad inexistente. Una historia puede cumplir todas las afirmaciones y aun así arrojar hallazgos, porque "el agente llegó al final" y "las herramientas se lo pusieron fácil" son preguntas distintas.

Algunos hallazgos extraídos directamente de ejecuciones reales:

• data_whtml_builder rechaza múltiples elementos raíz por llamada, lo que obliga al agente a dividir tres secciones en inserciones separadas y ordenarlas a la inversa; la herramienta debería admitir fragmentos con múltiples raíces.
• data_style_tool devuelve respuestas de más de 71 KB que superan los límites de tokens, obligando al agente a usar Bash para analizarlas.
• Webflow cambia automáticamente el nombre de las clases CSS en caso de conflicto (.hero se convierte en .hero-1-2-3), rompiendo silenciosamente el nombre de clase previsto por el agente sin ninguna advertencia de la herramienta.

Ninguno de estos son errores de aprobado o suspenso. Todas las historias se completaron. Pero cada uno es un comentario específico sobre el producto que surgió porque un agente se topó con el problema, no porque alguien adivinara qué podría salir mal. Esos hallazgos permanecen en el registro junto a la puntuación, por lo que una marca de verificación verde ya no borra el camino que el agente tuvo que recorrer.

¿Qué oculta una sola ejecución?

Una sola ejecución exitosa puede ocultar variaciones importantes, por lo que el arnés puede ejecutar la misma historia repetidamente con un sitio y una sesión de agente nuevos cada vez. Inicialmente, esto es una herramienta de diagnóstico, no una garantía de fiabilidad estadística. En un diagnóstico temprano de tres ejecuciones, las afirmaciones deterministas se cumplieron en las tres, mientras que las puntuaciones de calidad de diseño fueron del 40%, 80% y 85%. Tres observaciones no bastan para estimar la distribución de éxito subyacente, pero revelaron algo que el resumen original ocultaba: la ejecución de las herramientas era estable, pero la calidad del resultado no.

El resumen original de la consola reportaba una media de 1.00 y una desviación estándar de 0.00 porque la agregación solo veía la puntuación determinista. Ese resultado era matemáticamente correcto pero operativamente engañoso. Ahora reportamos esas dimensiones por separado y conservamos los resultados brutos de cada ejecución: las comprobaciones deterministas pasaron con 1.00 en las tres ejecuciones; la calidad del diseño obtuvo un 40%, 80% y 85%. A medida que aumentamos el tamaño de las muestras, la misma infraestructura podrá respaldar análisis de fiabilidad y regresión más sólidos.

La señal obvia no es la única señal

Un juez LLM que evalúa una captura de pantalla solo ve eso: una imagen. Dos páginas pueden verse idénticas a nivel de píxeles, pero una puede estar construida con una estructura significativa (<nav>, <section>, <button>) y la otra ser un caos de etiquetas div. Esa es una diferencia real en cuanto a accesibilidad y mantenimiento, y es invisible para una imagen.

Añadimos semantic_html_ratio, una señal determinista que no depende de LLM y que se calcula a partir del HTML renderizado que ya capturamos para la imagen: es la fracción de etiquetas semánticas frente a contenedores genéricos, combinada entre páginas según el volumen de marcado en lugar de un promedio simple. No es un filtro de aprobado/suspenso. Los divs contenedores son normales, y el propio constructor visual de Webflow es, por naturaleza, muy denso en divs, pero esto nos da una segunda señal independiente para comparar ejecuciones y observar tendencias a lo largo del tiempo.

La cobertura del agente anfitrión es parte de la cobertura de evaluación

Esta es la que más importó en la práctica. OpenAI rechazó uno de nuestros envíos de la aplicación ChatGPT después de que un agente intentara usar una herramienta de lienzo de diseño que requiere una pestaña activa del Diseñador de Webflow, algo que una sesión de ChatGPT nunca puede tener. Ejecutamos los mismos prompts rechazados a través de nuestro sistema de pruebas repetidamente y nunca reprodujimos el fallo. Ni una sola vez.

La razón era incómodamente simple: el sistema de pruebas solo había sido operado por Claude, y Claude prácticamente nunca mordió el anzuelo de esa guía de herramientas estática. El rechazo en producción provino de un modelo de la familia GPT. Habíamos construido un sistema de evaluación real y nunca lo habíamos ejecutado contra el agente que realmente estaba fallando en producción.

Así que añadimos un segundo controlador que invoca a la CLI de Codex de OpenAI de la misma manera que el original invoca a Claude Code. Ambos comparten un núcleo de orquestación: el aprovisionamiento, la puntuación, los jueces, las capturas de pantalla, los reintentos y la carga son idénticos. Solo difiere la parte de "iniciar el agente y analizar su salida".

Luego realizamos una comparación controlada: el prompt original frente a uno reforzado con una instrucción explícita de "no usar herramientas de lienzo de diseño", con cinco repeticiones independientes cada uno, en ambos controladores.

La misma tarea y el mismo servidor MCP produjeron un comportamiento materialmente diferente entre Claude Code y la CLI de Codex. Este experimento no aísla el modelo subyacente de la orquestación del anfitrión —y, operativamente, no necesita hacerlo—. Los usuarios experimentan el sistema combinado: modelo, instrucciones del sistema, presentación de herramientas, gestión de contexto y política de ejecución. La lección no fue que un modelo fuera mejor que otro. Fue que validar contra un solo anfitrión de agente nos dio una confianza que no se trasladaba a otro entorno. Todas las funciones de generación de confianza mencionadas, incluidas las pruebas de repetición, las señales semánticas y el juicio de transcripciones, ahora se ejecutan de forma idéntica en ambos anfitriones, porque esas capacidades residen en el núcleo compartido y no en código específico de Claude. Lo que sea que verifiquemos de ahora en adelante, lo verificaremos en ambos.

Por qué esto es importante de cara al futuro

Perseguir una marca de verificación verde nunca fue el objetivo. Antes de lanzar algo, podemos decir algo específico y cierto: ejecutamos esta tarea exacta, varias veces, contra varios agentes reales, y esto es lo que sucedió realmente. Ese es un tipo de confianza diferente a simplemente pasar pruebas.

• Cada cambio en el esquema de herramientas pasa por el conjunto de historias antes de lanzarse. Las mismas historias pueden apuntar a un servidor MCP que se ejecuta localmente, por lo que las regresiones pueden detectarse en una solicitud de extracción (pull request) en lugar de después del despliegue. Cada reenvío de la aplicación ChatGPT se verifica primero contra ambos controladores, de modo que una corrección se comprueba contra la familia de modelos que realmente falló, no solo contra la que resultó pasar. Una historia inestable aparece como tal, con variaciones, en lugar de tener suerte en la integración continua y sorprender a alguien más tarde.

El conjunto de pruebas ahora se ejecuta cada noche, convirtiendo la deriva en un número que cambia todos los días en lugar de una queja de producción que alguien tiene que rastrear semanas después.

El conjunto nocturno nos brinda una cobertura continua, pero el sistema de pruebas es igual de útil en el trabajo diario de producto e ingeniería. Un ingeniero que cambia una herramienta, o alguien del equipo de producto que valida una nueva capacidad, puede ejecutar manualmente exactamente las historias y la cobertura de agente que le interesan antes de que se lance nada.

Convertimos el conocimiento operativo en una habilidad de Claude Code, /eval-harness-runbook. Alguien puede describir lo que quiere probar, y la habilidad se encarga de la configuración, la cobertura relevante, el nombre del experimento y los hallazgos posteriores a la ejecución. Eso convierte al sistema de pruebas en una superficie de autoservicio para ingeniería y producto.

Ejecutarlo ha pasado de conocer el conjuro a simplemente preguntar y obtener una respuesta.

Hacia dónde se dirige

El trabajo a corto plazo es operativo: marcar automáticamente las herramientas sin cobertura de historias y convertir cada ejecución nocturna en un informe de regresiones, nuevos hallazgos y variaciones notables que llegue a donde la gente ya mira.

La pregunta más difícil es qué significa realmente una puntuación. Hoy en día, el resumen de cada historia, incluido lo que cuenta como "bueno", proviene de quien la escribió. Es útil, pero inventado. Queremos un techo de referencia de oro: construir manualmente una versión ideal de una historia emblemática, puntuarla a través del mismo juez y expresar las ejecuciones futuras en relación con ese techo, en lugar de tratar una puntuación simple de 0 a 4 como algo que se explica por sí mismo.

Y el conjunto de historias en sí no debería permanecer congelado tras el lanzamiento. En este momento refleja lo que imaginamos que los usuarios podrían pedir. Con el tiempo, queremos nuevas historias basadas en patrones de uso reales y análisis, no en datos de usuario sin procesar, para que lo que realmente sucede en el mundo enseñe al conjunto qué probar a continuación. Esa es la versión de este sistema de pruebas que vale la pena construir: no solo detectar lo que pensamos que debíamos comprobar, sino aprender lo que no.