Delphi, KAI y ExeWatchMCP: ¿y si tu asistente de IA leyera los errores de tus clientes y los corrigiera?

El lunes por la mañana abres el proyecto en Delphi o en C++Builder, le escribes a KAI una línea sobre el error que tuvo el cliente XYZ, y KAI va a leerlo por su cuenta. Te cuento cómo se llega ahí con ExeWatchMCP, y por qué, para quien programa en RAD Studio, cambia la forma de trabajar.

TL;DR: ExeWatch tiene un servidor MCP, ExeWatchMCP. Lo registras en KAI, el asistente de IA de RAD Studio, y KAI lee por su cuenta los errores y las lentitudes que tus clientes tienen en producción. Abres el proyecto Delphi o C++Builder, le dices “arregla el error del cliente XYZ” y parte de lo que ha pasado de verdad: más abajo tienes una sesión real. Funciona también con Claude Code, Codex y los demás agentes MCP, al final del artículo.

Aquí está la revolución

Un cliente te dice que ha visto un error. Le escribes una línea a KAI, y KAI hace el resto: lee la producción, encuentra el punto en el código, lo corrige, compila. Todo en el IDE, en el mismo chat.

Es una sesión real en un proyecto mío en Delphi 13 (RecommenderPro, un servidor REST). Las capturas están en inglés porque KAI y mi sesión lo están. No le di ni cliente ni versión, solo esta frase: “A client told me they saw an error in this app this afternoon. Check ExeWatch.”

KAI llama a exewatch_guide, exewatch_apps y exewatch_groups (la primera llamada a groups da error y KAI la repite), y me dice que en las últimas 24 horas hay dos problemas distintos: una licencia no válida, cuatro veces, y un fallo en la importación de un CSV, una vez. También dice lo que no sabe: “I haven’t read any code yet”, y que para entender cuál de los dos es el del cliente necesitaría la hora local del cliente. No adivina.

Le contesto: “OK, check it and fix it!”

KAI lee los logs del fallo, busca en el proyecto, abre RPServices.BulkU.pas y encuentra la causa: el separador esperado es el punto y coma y el fichero recibido estaba separado por comas, así que el parser veía una sola columna y decía “1 value per row”, un mensaje que no ayuda a nadie. Cambia el mensaje, que ahora nombra la fila y el separador requerido, y compila con el IDE.

De la frase “un cliente ha visto un error” al código modificado y compilado: un chat, dentro del IDE, sin que yo haya copiado un stack trace en un prompt. En el error de licencia KAI no ha tocado el código: el log indica un fichero de licencia no válido, así que es un problema de fichero y de configuración. También ha notado que ExeWatch no tiene stack trace para estos dos errores, porque el proyecto no está compilado con el map file detallado: lo tienes explicado más abajo.

El código ya no es el centro

Hasta ahora el código era el centro y la producción un sitio que visitabas. Un cliente llamaba, tú abrías el dashboard, copiabas el stack, lo pegabas en el prompt del agente. El agente conocía el código fuente y nada más: encontraba tres sitios sospechosos, elegía uno, y si era el equivocado el crash seguía ahí y tú tenías un cambio más que revisar.

Ahora el centro es lo que pasa en producción, y el código se adapta. El agente lee el error, la versión, cuántas veces ha ocurrido, en qué clientes, después de qué acciones, y solo después abre el fichero. El flujo es este: el código va a producción, ExeWatch recoge lo que pasa, el agente lo lee mientras modifica el código, el cambio vuelve a producción y ExeWatch te muestra si el error ha desaparecido. Ya no haces cambios a ciegas. Es un game changer.

Qué puedes pedirle

Las peticiones las escribes como se las dirías a un compañero, en español o en inglés. Por ejemplo:

Customer XYZ had an error last night on version 2.3.
Look it up in ExeWatch, find the spot in the code and fix it.

Check in ExeWatch where this program is slow
when opening the customer records screen, explain why and optimize it.

En el primer caso KAI busca el error, lee el stack trace, llega a la unit y a la línea, mira los breadcrumbs para entender qué estaba haciendo el usuario y te propone la corrección sobre tu código. En el segundo parte de los timing reales, no de su idea de dónde podría estar el cuello de botella. A menudo son dos sitios distintos.

Por qué en RAD Studio es otra cosa

Darle a un agente visibilidad sobre lo que pasa en producción es un superpoder. El bug fixing se vuelve mucho más rápido, porque el agente parte del error verdadero y no tiene que buscarlo, y reaccionas a lo que pasa en los clientes en el tiempo de una conversación, no de un ticket.

KAI está donde estás tú, dentro del IDE, con el proyecto abierto. Con ExeWatchMCP, en el mismo sitio donde escribes el código preguntas también qué ha pasado en los clientes, sin navegador, sin copiar y pegar, sin cambiar de herramienta. Delphi y C++Builder con KAI y con la producción a la vista funcionan mejor, y eso es lo que quiero enseñar a la comunidad de Embarcadero.

Qué es ExeWatchMCP

Es un paquete Python, ExeWatchMCP en PyPI: pip install ExeWatchMCP y tienes el servidor (exewatch-mcp) más la línea de comandos exewatch. MCP es el protocolo con el que un agente de IA descubre y ejecuta herramientas externas; he hablado de él en No solo MCP. Un agente IA real, embebido en tu aplicación Delphi. y en MCP Server para Delphi: Conecta Tus Aplicaciones a la IA con DMVCFramework. Las herramientas que tu agente se encuentra son estas:

Cómo lo conectas a KAI

La clave de API la creas en ExeWatch y es de solo lectura. En RAD Studio ve a Tools > Options > Kai > Chat > MCP Servers > Custom, añade un servidor y rellena cuatro campos: el nombre (exewatch-mcp), el tipo (Local), el comando de arranque (exewatch-mcp) y una variable de entorno EXEWATCH_API_KEY con tu clave. La clave vive ahí, no en el prompt.

Si el IDE no encuentra exewatch-mcp en el PATH, escribe la ruta completa del comando, o usa python -m exewatch_cli mcp.

Una cosa para quien trabaja en Delphi: el stack trace llega solo si compilas el programa con el map file detallado y los stack frames activados. Si ya usas madExcept o EurekaLog, puedes darle a ExeWatch su stack trace con una pequeña unit de enlace: lo expliqué en Integrar ExeWatch en Proyectos Delphi que Ya Usan madExcept, y el mismo esquema vale para EurekaLog.

Qué puede hacer y qué no

• Solo lectura. La clave es de solo lectura: el agente no escribe nada en ExeWatch.
• Clave con alcance limitado. Cuando creas la clave eliges qué puede leer: una sola aplicación, un grupo de aplicaciones, o todas. Un consultor externo recibe una clave para la única app en la que trabaja y no ve las demás.
• Planes PRO y BUSINESS. Las claves de API están disponibles en los planes PRO y BUSINESS, tanto en el cloud como on-premises. Si ExeWatch te pide hacer upgrade al crear la clave, tu plan no las incluye.
• El texto que llega del campo no es tuyo. Mensajes y stack traces los escribe el software de los clientes, y en teoría cualquiera que consiga hacerlo hablar. Por eso cada respuesta lleva "untrusted_content": true, y el agente la trata como datos que leer, nunca como instrucciones que ejecutar.
• Ventanas de tiempo. Sin filtros una consulta cubre hasta 90 días (24 horas si no dices nada). Filtrando por texto, tag, versión o sesión el máximo es 7 días, y lo mismo vale para los timing.
• La versión es un texto exacto. 2.3 no encuentra 2.3.0.145. Si no encuentra nada, el agente repite sin filtro y lee la versión en los resultados.
• El código lo revisas tú. Como manda la buena práctica, el agente propone el cambio en el código y tú haces la review como con cualquier otro cambio.

Funciona también con Claude Code, Codex y los demás

ExeWatchMCP es un servidor MCP estándar, así que no está atado a KAI. Con Claude Code:

claude mcp add exewatch --env EXEWATCH_API_KEY=<your key> -- exewatch-mcp

Con Codex es lo mismo con codex mcp add, o una entrada [mcp_servers.exewatch] en ~/.codex/config.toml. Cualquier otro agente o asistente que hable MCP se configura igual. Lo eliges tú.

En este artículo he hablado de Delphi y C++Builder porque es ahí donde nació ExeWatch y donde la integración con KAI tiene más sentido. Los SDK de ExeWatch cubren también .NET, Python y JavaScript, y el servidor es el mismo.

¿Quieres verlo en directo?

Lo muestro en directo en ITDevCon, Roma, 19 y 20 de noviembre: KAI abierto sobre un proyecto Delphi, un error real llegado desde ExeWatch, y el agente que lo resuelve delante de ti. Después hablaré de ello en algunos webinars y en otras conferencias, Ekon entre ellas. Las fechas las iré poniendo aquí a medida que las confirme.

Para entender qué recoge ExeWatch hoy, lee ExeWatch 1.35: Nested Timing Traces para Delphi y .NET y ExeWatch: Monitoreo de Software Proactivo de la Seguridad Pasiva a la Observabilidad. El resto está en exewatch.com.

Preguntas frecuentes

¿Qué es ExeWatchMCP? Es el servidor MCP de ExeWatch. Permite a un agente de coding leer errores, stack traces, breadcrumbs, versiones y timing de las aplicaciones monitorizadas, mientras trabaja sobre tu código.

¿Con qué agentes funciona? Con KAI, el asistente de IA de RAD Studio para Delphi y C++Builder, y con cualquier otro entorno que soporte el Model Context Protocol, como Claude Code y Codex.

¿Cómo lo instalo? pip install ExeWatchMCP (Python 3.9 o posterior), y luego registras exewatch-mcp en tu agente con la clave de API en el entorno.

¿El agente puede modificar los datos en ExeWatch? No. La clave es de solo lectura.

¿Hace falta un plan de pago? Sí. Las claves de API están disponibles en los planes PRO y BUSINESS, cloud y on-premises.

¿Puedo dar acceso a un consultor sobre una sola app? Sí. La clave se limita a una aplicación, a un grupo de aplicaciones o a todas.

¿Funciona solo con Delphi y KAI? No, pero este artículo parte de ahí. ExeWatch tiene SDK para Delphi, C++Builder, .NET, Python y JavaScript, y el servidor MCP es el mismo para todos.

¿Dónde lo veo en acción? En ITDevCon, en Roma, el 19 y 20 de noviembre de 2026.