Claude Code recuperó un contrato compartido mediante dos llamadas MCP sin memoria previa
14 de octubre de 2026 · 3 min de lectura
Una sesión nueva de Claude Code identificó el contrato compartido de una aplicación de soporte en únicamente dos llamadas al Protocolo de Contexto de Modelos y luego agotó la información disponible en los registros de dependencias. El agente operó sobre un sistema construido anteriormente y versionado en una plataforma de integración continua, demostrando capacidad para reconstruir contexto arquitectónico sin historial de conversación ni archivos locales, aunque encontró límites al verificar comportamientos en tiempo de ejecución y rutas de interfaz de programación de aplicaciones.
El experimento comenzó con un espacio de trabajo vacío donde el agente detectó la ausencia de componentes locales e infirió que la consola de soporte residía de forma remota. Utilizando una herramienta de lectura de alcance a través del protocolo mencionado, el sistema recuperó cuatro componentes versionados públicamente: una aplicación React, un servicio Express respaldado por una base de datos NoSQL, una entidad de ticket compartida y un componente de plataforma que unifica el acceso. Esta recuperación inicial permitió al agente comprender la estructura del proyecto basándose exclusivamente en metadatos de versión y dependencias registradas automáticamente durante la construcción del software.
La documentación de la clase de la entidad compartida indicaba explícitamente que era utilizada tanto por el servicio de soporte como por la aplicación orientada al agente. Esta información, contenida en las referencias de la interfaz de programación de aplicaciones, sustituyó la necesidad de memorias previas o notas automáticas generadas en sesiones anteriores. El agente procedió a importar los componentes, inspeccionar el código fuente e implementar una funcionalidad de filtrado del lado del cliente dentro de la aplicación, manteniendo intactos el servicio backend y la entidad compartida. La validación posterior reportó cuarenta y una pruebas exitosas, incluyendo nueve nuevas pruebas específicas para la lógica de filtrado implementada.
Sin embargo, los registros de construcción mostraron limitaciones significativas al abordar el comportamiento dinámico del sistema. Aunque la documentación listaba las rutas esperadas para la gestión de tickets, nada en los registros verificaba automáticamente que estas coincidieran con la implementación real del servicio en producción. La concordancia entre las rutas definidas y las ejecutadas requirió revisión manual y pruebas empíricas, ya que los metadatos estáticos no pueden garantizar la coherencia operativa en tiempo de ejecución. Además, algunas pruebas de integración omitían su ejecución cuando la base de datos temporal no podía iniciarse en el entorno de integración continua, lo que significaba que una construcción exitosa no aseguraba que todas las validaciones de persistencia se hubieran ejecutado realmente.
La verificación de la persistencia de datos requirió intervención humana directa para crear un ticket, añadir un comentario y reiniciar la plataforma contra la misma base de datos para confirmar que la información permanecía almacenada. El proyecto se mantiene como una demostración con una cuenta predefinida y secretos de firma públicos, dejando pendientes tareas de ingeniería ordinarias como el control de concurrencia, las migraciones de esquemas, los procedimientos de recuperación y las pruebas obligatorias de base de datos. Estos aspectos representan el tipo de trabajo complejo donde se requiere la atención de un ingeniero humano, más allá de las capacidades actuales de automatización basadas únicamente en registros de dependencias.
La comparación entre archivos de memoria y registros de dependencias revela diferencias fundamentales en la frescura y precisión del contexto. Los archivos de memoria contienen decisiones humanas y preferencias registradas en momentos específicos, con marcas de tiempo que indican su vigencia, pero carecen de un vínculo directo con versiones específicas del código. Por el contrario, los registros de dependencias son parte intrínseca de cada versión de componente creada por el sistema de construcción, registrando relaciones exactas sin intervención humana y sin posibilidad de desviación respecto a la versión que describen. En esta prueba, la ausencia de conversación previa y código local demostró que los registros automatizados fueron suficientes para localizar y respetar contratos compartidos, aunque insuficientes para validar comportamientos complejos del sistema.