Uno Platform ist der Ansicht, dass das größte Problem beim Einsatz von KI-Agenten zur Entwicklung plattformübergreifender .NET-Anwendungen nicht im Schreiben des Codes liegt, sondern darin festzustellen, ob der Code nach dem Start der Anwendung wie vorgesehen funktioniert. Ein Agent kann eine Seite mit Einstellungen erzeugen, die sich kompilieren und bauen lässt, aber Layout- oder Verhaltensfehler enthalten, die erst in der tatsächlichen Anwendung sichtbar werden.
Um diese Lücke zu schließen, entwickelte Uno Platform zwei Server in C# unter Verwendung des offiziellen MCP C# SDK, das Microsoft in Zusammenarbeit mit der Community entwickelt. Der erste Server konzentriert sich auf die Bereitstellung von Wissen und Dokumentation, während der zweite den Agenten mit einer tatsächlich laufenden Anwendung verbindet, sodass der Agent sie starten, untersuchen und mit ihr interagieren kann.
Zwei Server mit unterschiedlichen Aufgaben und Zeitzyklen
Die grundlegende Designentscheidung von Uno Platform bestand darin, die Frage „Was sollte korrekt sein?“ von der Frage „Was geschieht gerade?“ zu trennen. Der Dokumentationsserver verarbeitet Informationen, die sich ändern, wenn neue Plattformversionen veröffentlicht oder Seiten überarbeitet werden, während der Anwendungsserver mit dem Zustand einer bestimmten Laufsitzung arbeitet, der sich während der Ausführung der Anwendung verändert.
Der Dokumentationsserver ist öffentlich unter der Adresse mcp.platform.uno/v1 gehostet und arbeitet über HTTP zustandslos. Er stellt Werkzeuge bereit, um in der offiziellen Dokumentation zu suchen und vollständige Seiten im Markdown-Format abzurufen, ergänzt um Anweisungen für die Arbeit mit einer laufenden Anwendung sowie Regeln für die Verwendung gängiger Uno-Platform-APIs. Außerdem enthält er zwei Prompts: /new zum Erstellen einer Anwendung nach den aktuellen Best Practices und /init zum Initialisieren eines Gesprächs, das mit einer bestehenden Codebasis verknüpft ist.
Der Vorteil des Hostings dieses Servers besteht laut dem veröffentlichten Experiment darin, dass sich die Aktualisierung einer einzelnen Dokumentationsseite beim nächsten Aufruf des Servers durch die Agenten auswirkt, anstatt die Anweisungen in ein NuGet-Paket einzubetten, das eine neue Version erfordert.
Der Anwendungsserver läuft als .NET-Tool über stdio auf dem Gerät des Entwicklers und verbindet den Agenten mit dem Uno DevServer. Er ist ein zustandsbehafteter Server, der für eine einzelne Sitzung vorgesehen ist. Er kann die Anwendung im Debugmodus mit aktiviertem Hot Reload starten, einen Screenshot aufnehmen, eine XML-Darstellung des visuellen Elementbaums extrahieren und anschließend Klicks, Tastatureingaben, Texteingaben sowie Aktionen von Automatisierungselementen ausführen.
Die Validierung der Benutzeroberfläche erfordert mehr als einen Screenshot
Uno Platform betrachtet das Werkzeug für den visuellen Elementbaum als den wichtigsten Teil des Validierungszyklus. Ein Screenshot hilft dem Agenten zu erkennen, dass etwas falsch aussieht, während der Elementbaum das problematische Element und seine Eigenschaften sichtbar macht. Praktisch ausgedrückt: Pixel eignen sich zur Erkennung, die Struktur zur Diagnose, und der Agent benötigt beides.
Die Plattform empfiehlt, nach Möglichkeit uno_app_element_peer_action anstelle von Koordinatenklicks über uno_app_pointer_click zu verwenden, da Koordinatenklicks von unterschiedlichen Fenstergrößen und Pixeldichten beeinflusst werden, während Automatisierungsaktionen an die Elemente selbst gebunden sind. Diese Empfehlung wurde in die Beschreibung des Werkzeugs aufgenommen und nicht in ein separates Dokument, das der Agent möglicherweise nicht lädt, da die Werkzeugbeschreibung die Auswahlentscheidung unmittelbar beeinflusst.
Mit diesen Werkzeugen kann der Agent die Benutzeroberfläche ändern, die Anwendung anschließend neu laden, einen Screenshot aufnehmen, den visuellen Baum lesen, einen Interaktionsablauf ausführen und feststellen, ob das Ergebnis vor der Übergabe der Änderung den Anforderungen entspricht. Uno Platform vergleicht diesen Ansatz mit den Playwright-Werkzeugen für Webanwendungen, richtet ihn jedoch auf native .NET-Anwendungen aus, die unter Windows, macOS, Linux, iOS, Android und WebAssembly laufen.
Die Kosten der Werkzeuge sind Teil des Kontextdesigns
Das Experiment lenkt die Aufmerksamkeit auf eine praktische Einschränkung, die in der Diskussion über MCP häufig übersehen wird: Werkzeugdefinitionen verbrauchen Kontextfenster des Modells, bevor überhaupt eine Frage gestellt wird. Uno Platform gab an, dass der Dokumentationsserver etwa 6,4 Tausend Token verbraucht, während der Anwendungsserver etwa 1,5 Tausend Token benötigt. Zum Vergleich: Der in derselben Sitzung integrierte GitHub-MCP-Server verbraucht etwa 5,2 Tausend Token.
Daher sind Werkzeugbeschreibungen nicht bloß technische Dokumentation; laut dem Artikel stellen sie eine Form der Steuerung oder Aufforderung dar, die die Werkzeugauswahl des Agenten beeinflusst. Daraus ergibt sich, wie wichtig es ist, Namen, Beschreibungen und Eingabeschemata kurz und signalstark zu gestalten und wichtige operative Präferenzen an der Stelle einzubeziehen, die das Modell bei seiner Entscheidung liest.
Was ändert sich praktisch für Entwickler?
Uno Platform stellt nicht nur einzelne Werkzeuge bereit, sondern ergänzt sie um sogenannte Skills. Dabei handelt es sich um strukturierte Abläufe, die festlegen, wann Werkzeuge verwendet werden, in welcher Reihenfolge dies geschieht und woran die Vollständigkeit der Aufgabe erkannt wird. Die Bibliothek umfasst Szenarien wie MVUX, Zustand, Datenquellen, Navigation, Formatierung, Elemente des Uno Toolkit und Tests sowie einen Skill namens uno-testing-ui zur Automatisierung von UI-Tests über den Anwendungsserver.
Diese Struktur verbindet aktuelle Dokumentation, eine live laufende und untersuchbare Anwendung sowie vordefinierte Arbeitsabläufe. Die Plattform erklärt, dass diese Komponenten Uno Platform Studio 3.0 unterstützen, das eine vollständig plattformübergreifende .NET-Anwendung direkt im Browser erstellt. Dies basiert auf dem Microsoft Agent Framework für Planung und Ausführung sowie auf einem Roslyn-Arbeitsbereich zum Kompilieren, Laden von Assemblys, Auflösen von NuGet-Änderungen und erneuten Laden des Ergebnisses in die laufende Anwendung.
Redaktionelle Einschätzung von certi.news: Der tatsächliche Wert dieses Experiments liegt nicht darin, einen weiteren Agenten zum Schreiben von Code hinzuzufügen, sondern darin, den Agenten von der Rolle eines Textgenerators zu einem Akteur weiterzuentwickeln, der eine aktuelle Wissensquelle abfragen und sein Ergebnis an einer echten Anwendung testen kann. Die Trennung der beiden Server liefert außerdem eine auf andere MCP-Projekte übertragbare Designregel: Langfristiges Wissen sollte vom Laufzeitstatus getrennt werden, und HTTP oder stdio sollte anhand der Bereitstellungsarchitektur statt nach formaler Vorliebe gewählt werden.
Dennoch belegt der Artikel nicht, dass dieser Ansatz die Notwendigkeit menschlicher Überprüfung beseitigt oder die Korrektheit der Anwendung in allen Fällen garantiert. Er beschreibt das Experiment und die Werkzeuge von Uno Platform, liefert jedoch keine unabhängigen Messwerte zu Fehlererkennungsraten oder Codequalität. Auch die Kosten der Werkzeugdefinitionen sowie die Abhängigkeit des Anwendungsservers vom Uno DevServer und von einer lokalen Sitzung bleiben praktische Einschränkungen, die Teams vor einer Übernahme dieses Modells bewerten sollten.