Uno Platform estime que le principal problème lié à l’utilisation d’agents d’IA pour construire des applications .NET multiplateformes ne réside pas dans l’écriture du code, mais dans la capacité à déterminer si le code fonctionne correctement une fois l’application lancée. L’agent peut produire une page de paramètres qui se compile et peut être traduite, mais qui comporte des erreurs de mise en page ou de comportement ne se manifestant que dans l’application réelle.
Pour combler cette lacune, Uno Platform a construit deux serveurs en C# à l’aide du package officiel MCP C# SDK, développé par Microsoft en collaboration avec la communauté. Le premier serveur se concentre sur la fourniture de connaissances et de documentation, tandis que le second relie l’agent à une application réellement en cours d’exécution, afin que l’agent puisse la lancer, l’inspecter et interagir avec elle.
Deux serveurs, deux missions et deux cycles temporels différents
La décision fondamentale dans la conception d’Uno Platform a consisté à séparer le problème de « ce qui devrait être correct » de celui de « ce qui se passe actuellement ». Le serveur de documentation traite des informations qui évoluent lorsque la plateforme est mise à jour ou que ses pages sont modifiées, tandis que le serveur d’application traite l’état d’une session d’exécution donnée, qui change pendant l’exécution de l’application.
Le serveur de documentation est hébergé publiquement à l’adresse mcp.platform.uno/v1 et fonctionne via HTTP, sans état. Il fournit des outils permettant de rechercher dans la documentation officielle et de récupérer des pages complètes au format Markdown, ainsi qu’une configuration des règles de travail avec une application en cours d’exécution et des règles d’utilisation des API courantes d’Uno Platform. Il comprend également deux prompts : /new, pour créer une application conformément aux meilleures pratiques actuelles, et /init, pour initialiser une conversation associée à une base de code existante.
Selon l’expérience publiée, l’intérêt d’héberger ce serveur réside dans le fait que la mise à jour d’une seule page de documentation est répercutée aux agents lors de leur prochain appel au serveur, au lieu d’intégrer les instructions dans un package NuGet nécessitant une nouvelle version.
Le serveur d’application, quant à lui, fonctionne comme un outil .NET via stdio sur la machine du développeur et relie l’agent au service Uno DevServer. Il s’agit d’un serveur avec état, dédié à une seule session. Il peut lancer l’application en mode débogage avec Hot Reload activé, capturer une capture d’écran, extraire une représentation XML de l’arbre des éléments visuels, puis effectuer des clics, des pressions de touches, des saisies de texte et appeler les actions des éléments d’automatisation.
La vérification de l’interface exige plus qu’une capture d’écran
Uno Platform considère que l’outil d’arbre des éléments visuels constitue la partie la plus importante du cycle de vérification. Une capture d’écran aide l’agent à détecter que quelque chose semble incorrect, tandis que l’arbre des éléments révèle l’élément à l’origine du problème et ses propriétés. En pratique : les pixels conviennent à la détection, la structure au diagnostic, et l’agent a besoin des deux.
La plateforme recommande d’utiliser uno_app_element_peer_action plutôt que de cliquer sur des coordonnées via uno_app_pointer_click lorsque cela est possible, car les clics par coordonnées sont affectés par les différences de taille des fenêtres et de densité de pixels, tandis que les actions d’automatisation sont liées aux éléments eux-mêmes. Cette recommandation a été placée dans la description de l’outil, et non dans un document distinct que l’agent pourrait ne pas charger, car la description de l’outil influence directement le choix effectué.
Grâce à ces outils, l’agent peut modifier l’interface, recharger ensuite l’application, capturer l’écran, lire l’arbre visuel, exécuter un parcours interactif et déterminer si le résultat correspond à ce qui est demandé avant de livrer la modification. Uno Platform compare cette approche aux outils Playwright destinés aux applications web, en l’appliquant aux applications .NET natives fonctionnant sur Windows, macOS, Linux, iOS, Android et WebAssembly.
Le coût des outils fait partie de la conception du contexte
L’expérience attire l’attention sur une contrainte pratique souvent absente des discussions consacrées à MCP : les définitions des outils consomment une partie de la fenêtre de contexte du modèle avant même qu’une question soit posée. Uno Platform indique que le serveur de documentation consomme environ 6,4 milliers de tokens, tandis que le serveur d’application en consomme environ 1,5 millier. À titre de comparaison, le serveur GitHub MCP intégré à la même session consomme environ 5,2 milliers de tokens.
Les descriptions des outils ne constituent donc pas une simple documentation technique ; elles sont, selon l’article, une forme d’orientation ou de prompt qui influence le choix de l’outil par l’agent. D’où l’importance de rendre le nom, la description et le schéma d’entrée concis et riches en signal, tout en incluant les préférences opérationnelles importantes à l’endroit que le modèle lit lorsqu’il prend sa décision.
Qu’est-ce qui change concrètement pour les développeurs ?
Uno Platform ne se contente pas de fournir des outils isolés : elle ajoute ce qu’elle appelle des Skills, c’est-à-dire des procédures structurées qui définissent quand utiliser les outils, dans quel ordre et ce qui constitue l’achèvement de la tâche. La bibliothèque couvre des scénarios tels que MVUX, l’état, les sources de données, la navigation, le formatage, les éléments d’Uno Toolkit et les tests, avec un Skill nommé uno-testing-ui pour automatiser les tests d’interface via le serveur d’application.
Cette architecture associe une documentation à jour, une application réelle pouvant être inspectée et des procédures prédéfinies pour le flux de travail. La plateforme affirme que ces composants prennent en charge Uno Platform Studio 3.0, qui crée une application .NET entièrement multiplateforme directement dans le navigateur. Cette solution s’appuie sur Microsoft Agent Framework pour la planification et l’exécution, ainsi que sur un espace de travail Roslyn pour la compilation, le chargement des assemblys, la résolution des modifications NuGet et le rechargement du résultat dans l’application en cours d’exécution.
Lecture éditoriale de certi.news : la valeur réelle de cette expérience ne réside pas dans l’ajout d’un nouvel agent chargé d’écrire du code, mais dans le passage de l’agent du rôle de générateur de texte à celui d’un acteur capable d’interroger une source de connaissances à jour et de tester son résultat face à une application réelle. La séparation des deux serveurs fournit également un principe de conception applicable à d’autres projets MCP : séparer les connaissances à long terme de l’état d’exécution et choisir HTTP ou stdio en fonction de l’architecture de déploiement, plutôt que d’une préférence formelle.
Cependant, l’article ne démontre pas que cette approche élimine le besoin d’une revue humaine ni qu’elle garantit l’exactitude de l’application dans tous les cas. Il présente l’expérience et les outils d’Uno Platform, sans fournir de résultats de mesure indépendants concernant les taux de détection des erreurs ou la qualité du code. En outre, le coût des définitions d’outils et la dépendance du serveur d’application à Uno DevServer et à une session locale restent des contraintes pratiques que les équipes doivent évaluer avant d’adopter ce modèle.