Define → Plan → Apply → Build → Verify → Iterate .
Six steps. Verification built into every cycle, not as an afterthought, but as a gate.
Part 1
got you connected. Both MCPs work. You've seen them in action.
Now you need a process, not just "ask the AI and hope." The difference between developers who get value from AI assistants and those who don't is almost always workflow, not capability. The tools are the same. The loop is what matters.
The Uno Platform AI Dev Loop
Every step involves a specific action. Steps 2 and 5 are where the MCPs earn their keep.
Step by Step
Step 1 - Define: Write down what you're changing and how you'll know it worked. Be specific. "Add a settings page" is not acceptance criteria. "A SettingsPage with three ToggleSwitches, each bound to an IState, page reachable from MainPage navigation" is.
Step 2 - Plan: Ask the agent (via Uno MCP) to propose the changes. It searches the docs, reads your project conventions, and proposes file diffs that match your existing patterns. You review before applying.
Step 3 - Apply: Take the smallest safe patch. One feature per cycle. If the agent proposes eight file changes, question whether it can be split.
Step 4 - Build: dotnet build, run on your target. Nothing fancy here.
Step 5 - Verify: With the app running, use App MCP to inspect the visual tree (uno_app_visualtree_snapshot), take screenshots (uno_app_get_screenshot), and check DataContext state (uno_app_get_element_datacontext). Compare what's actually rendered against your acceptance criteria from Step 1.
Step 6 - Iterate: If verification reveals mismatches, feed the App MCP output back to the agent. "The visual tree shows the ToggleSwitch exists but its DataContext is null. Here's the snapshot. Fix the binding." This is where the loop gets powerful—you're giving the agent evidence, not just a vague "it doesn't work."
Key principle: Never skip Step 5. Code that compiles is not code that works. This is especially true for cross-platform UI, where something can render perfectly on Windows and break on Android.
Scaffold a Settings Page with Toggles and Persistence
Write acceptance criteria:
- — SettingsPage exists with three ToggleSwitch controls
-
—
Each toggle is bound to an
IState<bool>in a SettingsModel (MVUX) - — Toggle state persists via IWriteableOptions or local storage
- — SettingsPage is reachable from main navigation
- — All toggles default to false on first launch
Prompt for the agent:
"I want to add a SettingsPage to my Uno Platform app. Review my project structure. I need:
- • A SettingsModel (MVUX partial record) with three IState<bool> properties
- • A SettingsPage.xaml with three ToggleSwitches bound to those states
- • Navigation route registered so SettingsPage is reachable from MainPage
- • State persistence using the project's existing storage pattern
Use Uno MCP docs to verify the correct MVUX state pattern and navigation registration. Propose the minimal set of file changes. Match my existing naming, namespace, and folder conventions."
uno_platform_docs_search for MVUX states, navigation routes, and IWriteableOptions. Propose a SettingsModel using partial record with IState<bool>, the XAML page, and the navigation route registration.I've reviewed everything. Here's my proposed plan - 4 file changes total:
1. New file: Presentation/SettingsModel.cs
MVUX partial record with 3 IState<bool> properties, injecting
IWritableOptions<SettingsConfig> to persist toggles.
2. New file: Presentation/SettingsPage.xaml + code-behind
Three ToggleSwitch controls bound to the states, with NavigationBar,
matching existing page conventions.
3. New file: Models/SettingsConfig.cs
Immutable record with three bool? properties for persistence via
IWritableOptions.
4. Modified: App.xaml.cs
- Register SettingsConfig as a configuration section
- Add ViewMap<SettingsPage, SettingsModel>() in RegisterRoutes
- Add new("Settings", ...) nested route
What this uses:
- MVUX IState<bool> with State.Value() pattern (matching MainModel)
- IWritableOptions<SettingsConfig> for persistence
- Region-based navigation route registration (matching SecondPage pattern)
- No new NuGet packages needed
Unresolved questions:
- What should the three boolean settings represent? I'll use generic
labels: Notifications, Dark Mode, Analytics - want me to change these?
- Should SettingsPage be reachable from MainPage via a button, or just
registered as a route?Review the proposed files. Check that namespaces, folder locations, and patterns match your project. Apply the changes.
Run on your target.
Prompt for the agent:
"Use uno_app_start to verify runtime behavior:
- • Navigate to SettingsPage (or confirm it's reachable)
- • Take a screenshot of the SettingsPage
- • Get a visual tree snapshot of the SettingsPage
- • Verify: Three ToggleSwitches exist, each has a binding, page title is visible
Report pass/fail for each criterion with evidence from the visual tree."
uno_app_get_screenshot and uno_app_visualtree_snapshot. Parse the tree for ToggleSwitch elements. Report findings against each criterion.
If the visual tree shows ToggleSwitches but with null DataContext, feed the snapshot back:
"The visual tree snapshot shows the ToggleSwitches exist, but here's the output: [paste snapshot]. The DataContext appears to be null. Check the navigation route registration and verify the SettingsModel is being injected correctly."
The agent now has evidence to work with, not just your description of the problem.
Prompt Kit
These are reusable across any scenario. Customize the [BRACKETED] parts.
"Review my project structure via Uno MCP. I want to [GOAL]. Propose the minimal set of file changes. For each file, state: what changes, what's new, and why. Match my existing naming, namespace, and MVUX patterns."
"Based on the plan above, generate the code changes. Keep the diff as small as possible. Do not refactor unrelated code. Use MVUX patterns (partial record, IState, IFeed) as appropriate."
"Using App MCP, take a screenshot and get a visual tree snapshot of [PAGE]. Report: element hierarchy, bound property values, actual layout values (margins, padding, bounds), and any elements with null DataContext."
"Using App MCP, verify these criteria against the running app: [LIST CRITERIA] Report pass/fail for each with evidence from the visual tree or screenshot."
"Using App MCP, inspect [CONTROL] on [PAGE]. Call uno_app_get_element_datacontext on it. Report: DataContext type, bound property values, and whether any bindings resolve to null or fallback values."
"Based on the changes made to [FILES], generate a checklist of things to verify. Include cross-platform considerations for Windows, Android, and WebAssembly."
What's Next
You have the loop and two real scenarios. Part 3 covers the harder cases:
- — Debugging silent binding failures with App MCP evidence
- — Verifying cross-platform parity across multiple targets
- — Wiring up navigation with parameter passing
- — Knowing when to stop using MCP and just write the code yourself
Subscribe to Our Blog 
Subscribe via RSS
Back to Top
