Uno Platform believes that the biggest problem when using AI agents to build cross-platform .NET applications is not writing the code, but knowing whether the code works as intended after the application runs. An agent may produce a settings page that can be compiled and built, but it may contain layout or behavior errors that appear only inside the actual application.
To address this gap, Uno Platform built two servers in C# using the official MCP C# SDK package developed by Microsoft in collaboration with the community. The first server focuses on providing knowledge and documentation, while the second connects the agent to an actually running application, allowing the agent to launch, inspect, and interact with it.
Two Servers with Two Different Responsibilities and Lifecycles
The fundamental design decision at Uno Platform was to separate the question of “what should be correct?” from the question of “what is happening now?” The documentation server deals with information that changes when platform updates are released or its pages are modified, while the application server deals with the state of a specific running session that changes while the application is running.
The documentation server is publicly hosted at mcp.platform.uno/v1, and operates over HTTP without state. It provides tools for searching the official documentation and retrieving complete pages in Markdown format, in addition to initializing working rules for a running application and guidelines for using common Uno Platform APIs. It also includes two prompts: /new for creating an application according to current best practices, and /init for initializing a conversation associated with an existing codebase.
According to the published experience, the benefit of hosting this server is that updating a single documentation page is reflected to agents the next time they call the server, instead of embedding the guidance in a NuGet package that requires a new release.
The application server, meanwhile, runs as a .NET tool over stdio on the developer’s machine and connects the agent to Uno DevServer. It is a stateful server dedicated to a single session. It can launch the application in debug mode with Hot Reload enabled, capture a screenshot, extract an XML representation of the visual element tree, and then perform clicks, key presses, text input, and invoke automation-element actions.
Interface Verification Requires More Than a Screenshot
Uno Platform considers the visual element tree tool to be the most important part of the verification cycle. A screenshot helps the agent detect that something looks wrong, while the element tree reveals the element causing the problem and its properties. In practical terms: pixels are suitable for discovery, structure is suitable for diagnosis, and the agent needs both.
The platform recommends using uno_app_element_peer_action instead of coordinate-based clicking through uno_app_pointer_click whenever possible, because coordinate-based clicking is affected by differences in window sizes and pixel densities, whereas automation actions are associated with the elements themselves. This recommendation was placed in the tool description rather than in a separate document that the agent might not load, because the tool description directly affects the selection decision.
With these tools, the agent can modify the interface, reload the application, capture the screen, read the visible tree, execute an interactive flow, and determine whether the result matches the requirements before delivering the change. Uno Platform compares this approach to Playwright tools for web applications, while directing it at native .NET applications running on Windows, macOS, Linux, iOS, Android, and WebAssembly.
Tool Costs Are Part of Context Design
The experience draws attention to a practical constraint that is often absent from discussions about MCP: tool definitions consume part of the model’s context window before any question is asked. Uno Platform stated that the documentation server consumes approximately 6.4 thousand tokens, while the application server consumes approximately 1.5 thousand tokens. For comparison, the GitHub MCP server integrated into the same session consumes approximately 5.2 thousand tokens.
Therefore, tool descriptions are not merely technical documentation; according to the article, they are a form of guidance or prompting that affects the agent’s tool selection. This is why it is important to make the name, description, and input schema concise and high-signal, while including important operational preferences in the place the model reads when making its decision.
What Changes for Developers in Practice?
Uno Platform does not merely provide individual tools; it also adds what it calls Skills, which are organized procedures that specify when tools should be used, in what order, and what constitutes task completion. The library includes scenarios such as MVUX, state, data sources, navigation, formatting, Uno Toolkit elements, and testing, with a Skill named uno-testing-ui for automating interface testing through the application server.
This structure combines updated documentation, a live application that can be inspected, and predefined workflow procedures. The platform says these components support Uno Platform Studio 3.0, which creates a fully cross-platform .NET application entirely in the browser. This relies on Microsoft Agent Framework for planning and execution, and on a Roslyn workspace for compilation, loading assemblies, resolving NuGet changes, and reloading the result in the running application.
Editorial reading from certi.news: The actual value of this experience is not adding another agent to write code, but moving the agent from the role of a text generator to that of a party capable of querying an up-to-date knowledge source and testing its output against a real application. Separating the two servers also provides a design principle applicable to other MCP projects: separate long-term knowledge from runtime state, and choose HTTP or stdio based on the deployment architecture rather than on a superficial preference.
Nevertheless, the article does not prove that this approach eliminates the need for human review or guarantees application correctness in every case. It presents Uno Platform’s experience and tools, and does not provide independent measurement results for error-detection rates or code quality. The cost of tool definitions, along with the application server’s dependence on Uno DevServer and a local session, also remain practical constraints that teams should evaluate before adopting the model.