Programación y desarrollo de software

Cómo utiliza Uno Platform el protocolo MCP para verificar las aplicaciones .NET que construyen los agentes de inteligencia artificial

Uno Platform explica la experiencia de construir dos servidores para el protocolo Model Context Protocol: uno para proporcionar a los agentes de inteligencia artificial documentación actualizada y otro para interactuar con una aplicación .NET en ejecución y verificar su interfaz. La experiencia destaca que generar código es solo la mitad de la tarea, mientras que construir una aplicación fiable requiere proporcionar al agente contexto en tiempo real, herramientas de inspección y procedimientos claros.

2026-08-27
7 min de lectura
10 visitas
فريق تحرير certi.news
Cómo utiliza Uno Platform el protocolo MCP para verificar las aplicaciones .NET que construyen los agentes de inteligencia artificial

Uno Platform considera que el mayor problema al utilizar agentes de inteligencia artificial para construir aplicaciones .NET multiplataforma no es escribir el código, sino saber si el código funciona como debería después de ejecutar la aplicación. El agente puede producir una página de configuración que se compila y traduce correctamente, pero que puede contener errores de diseño o comportamiento que solo aparecen dentro de la aplicación real.

Para abordar esta brecha, Uno Platform construyó dos servidores en C# utilizando el paquete oficial MCP C# SDK, desarrollado por Microsoft en colaboración con la comunidad. El primer servidor se centra en proporcionar conocimientos y documentación, mientras que el segundo conecta al agente con una aplicación que se está ejecutando realmente, de modo que el agente puede iniciarla, inspeccionarla e interactuar con ella.

Dos servidores con dos tareas y ciclos temporales diferentes

La decisión fundamental en el diseño de Uno Platform fue separar el problema de «qué debería ser correcto» del problema de «qué está ocurriendo ahora». El servidor de documentación trata información que cambia cuando se publican actualizaciones de la plataforma o se modifican sus páginas, mientras que el servidor de aplicaciones trata el estado de una sesión de ejecución específica que cambia mientras la aplicación está funcionando.

El servidor de documentación está alojado públicamente en mcp.platform.uno/v1 y funciona mediante HTTP y sin estado. Proporciona herramientas para buscar en la documentación oficial y obtener páginas completas en formato Markdown, además de una configuración de reglas para trabajar con una aplicación en ejecución y reglas para utilizar las API comunes de Uno Platform. También incluye dos prompts: /new, para crear una aplicación conforme a las mejores prácticas actuales, y /init, para inicializar una conversación vinculada a una base de código existente.

La ventaja de alojar este servidor, según la experiencia publicada, es que actualizar una sola página de documentación se refleja en los agentes la próxima vez que lo invocan, en lugar de incluir las directrices en un paquete NuGet que necesita una nueva versión.

El servidor de aplicaciones funciona como una herramienta .NET mediante stdio en el dispositivo del desarrollador y conecta al agente con Uno DevServer. Es un servidor con estado, dedicado a una sola sesión. Puede iniciar la aplicación en modo de depuración con Hot Reload activado, capturar una captura de pantalla, extraer una versión XML del árbol de elementos visuales y después ejecutar clics, pulsaciones de teclas, introducción de texto y acciones sobre elementos de automatización.

Verificar la interfaz requiere más que una captura de pantalla

Uno Platform considera que la herramienta del árbol de elementos visuales es la parte más importante del ciclo de verificación. La captura de pantalla ayuda al agente a detectar que algo parece incorrecto, mientras que el árbol de elementos revela qué elemento causa el problema y cuáles son sus propiedades. En términos prácticos: los píxeles son adecuados para la detección, la estructura es adecuada para el diagnóstico y el agente necesita ambos.

La plataforma recomienda utilizar uno_app_element_peer_action en lugar de hacer clic mediante coordenadas con uno_app_pointer_click siempre que sea posible, porque los clics por coordenadas se ven afectados por las diferencias en el tamaño de las ventanas y la densidad de píxeles, mientras que las acciones de automatización están vinculadas a los propios elementos. Esta recomendación se incluyó en la descripción de la herramienta, no en un documento independiente que el agente podría no cargar, porque la descripción de la herramienta influye directamente en la decisión de selección.

Con estas herramientas, el agente puede modificar la interfaz, volver a cargar la aplicación, capturar la pantalla, leer el árbol visible, ejecutar un flujo interactivo y determinar si el resultado coincide con lo solicitado antes de entregar el cambio. Uno Platform compara este enfoque con las herramientas de Playwright para aplicaciones web, pero orientado a aplicaciones .NET nativas que se ejecutan en Windows, macOS, Linux, iOS, Android y WebAssembly.

El coste de las herramientas forma parte del diseño del contexto

La experiencia llama la atención sobre una limitación práctica que a menudo se omite en el debate sobre MCP: las definiciones de las herramientas consumen parte de la ventana de contexto del modelo antes de formular cualquier pregunta. Uno Platform indicó que el servidor de documentación consume aproximadamente 6,4 mil tokens, mientras que el servidor de aplicaciones consume aproximadamente 1,5 mil tokens. Como comparación, el servidor GitHub MCP integrado en la misma sesión consume aproximadamente 5,2 mil tokens.

Por tanto, las descripciones de las herramientas no son meramente documentación técnica; según el material, son un tipo de orientación o prompt que influye en la elección de la herramienta por parte del agente. De ahí la importancia de que el nombre, la descripción y el esquema de entrada sean breves y de alta señal, e incluyan las preferencias operativas importantes en el lugar que el modelo lee al tomar la decisión.

¿Qué cambia en la práctica para los desarrolladores?

Uno Platform no se limita a proporcionar herramientas independientes, sino que añade lo que denomina Skills, procedimientos estructurados que determinan cuándo se utilizan las herramientas, en qué orden y qué significa que la tarea esté completa. La biblioteca incluye escenarios como MVUX, el estado, las fuentes de datos, la navegación, el formato, los elementos de Uno Toolkit y las pruebas, junto con un Skill llamado uno-testing-ui para automatizar las pruebas de interfaz mediante el servidor de aplicaciones.

Esta estructura combina documentación actualizada, una aplicación activa que se puede inspeccionar y procedimientos predefinidos para el flujo de trabajo. La plataforma afirma que estos componentes son compatibles con Uno Platform Studio 3.0, que crea una aplicación .NET multiplataforma completa dentro del navegador. Esto se basa en Microsoft Agent Framework para la planificación y la ejecución, y en un espacio de trabajo de Roslyn para la compilación, la carga de ensamblados, la resolución de cambios de NuGet y la recarga del resultado en la aplicación en ejecución.

Lectura editorial de certi.news: el valor real de esta experiencia no consiste en añadir otro agente que escriba código, sino en trasladar al agente del papel de generador de texto al de una parte capaz de consultar una fuente de conocimiento actualizada y probar su resultado frente a una aplicación real. La separación de los dos servidores también ofrece una regla de diseño aplicable a otros proyectos MCP: separar el conocimiento a largo plazo del estado de ejecución y elegir HTTP o stdio en función de la arquitectura de despliegue, no de una preferencia formal.

Sin embargo, el material no demuestra que este enfoque elimine la necesidad de revisión humana ni que garantice la corrección de la aplicación en todos los casos. Presenta la experiencia y las herramientas de Uno Platform, pero no ofrece resultados de medición independientes sobre las tasas de detección de errores o la calidad del código. Además, el coste de las definiciones de las herramientas y la dependencia del servidor de aplicaciones de Uno DevServer y de una sesión local siguen siendo limitaciones prácticas que los equipos deberían evaluar antes de adoptar el modelo.

Fuente de la noticia
ف
Autor

فريق تحرير certi.news

De la misma categoría

También te puede interesar

Ver todas las noticias