Uno MCP gives your AI assistant access to up-to-date Uno Platform documentation and conventions. Use it when planning features and scaffolding code.
App MCP connects to your running application. Use it to verify that generated code actually works at runtime.
Together, they close the gap between "AI suggested this" and "this is verified."
Is this you?
You already know how to build cross-platform apps with Uno Platform or other cross-platform .NET technologies, past and present. Now you’re experimenting with AI—whether it’s agents, skills, MCPs, or whatever form it shows up in this week—and you’re trying to turn it into a workflow you can actually trust.
That’s where Uno Platform MCPs come in. They’re part of Uno Platform Studio, and they give your AI agents two things they usually lack:
— Current Uno knowledge (docs, conventions, best practices)
— Runtime truth (what your app actually rendered and did)
Knowing when to use each MCP is the difference between “AI suggested this” and “this is verified.” And once you feel that loop click, it brings back that early-days spark: shipping faster because you’ve got feedback you can rely on.
Two MCPs, Two Roles
Uno Platform provides two MCP servers. They do different jobs. Understanding which one to reach for, and when, is the whole mental model
Uno MCP (Remote)
https://mcp.platform.uno/v1.-
—
uno_platform_docs_search— searches Uno Platform docs -
—
uno_platform_docs_fetch— retrieves full documentation pages -
—
uno_platform_agent_rules_init— primes with development rules -
—
uno_platform_usage_rules_init— primes with API best practices
Built-in prompts: /new (scaffold new app), /init (prime existing session)
App MCP (Local)
dotnet dnx -y uno.devserver --mcp-app. It connects to your running application.-
—
uno_app_get_runtime_info— app PID, OS, platform details -
—
uno_app_get_screenshot— captures what the app looks like right now -
—
uno_app_visualtree_snapshot— live visual tree dump -
—
uno_app_pointer_click— clicks at X,Y coordinates -
—
uno_app_key_press/uno_app_type_text— keyboard input -
—
uno_app_element_peer_default_action— triggers automation peer actions
Pro license adds: uno_app_get_element_datacontext, uno_app_element_peer_action
When to Use Which
| "I want to..." | MCP to use |
|---|---|
| Plan a new feature | Uno MCP |
| Scaffold a page, model, and navigation route | Uno MCP |
| Check the correct MVUX pattern for my scenario | Uno MCP |
| Verify my page rendered correctly after a change | App MCP |
| Debug why a binding resolves to null | App MCP |
| Confirm layout matches across platforms | App MCP |
| Get a screenshot of the current app state | App MCP |
| Build a feature end-to-end with verification | Both, in sequence |
The key insight: Uno MCP helps you write code that follows conventions. App MCP confirms the code actually works at runtime.
Your First 30 Minutes
Don't try to build a feature yet. Start with three small tasks that confirm everything works. Full setup instructions live in the Uno Platform docs.
Ask your assistant:
"Search the Uno Platform docs for the recommended MVUX pattern for persisted settings. Summarize what you find."
uno_platform_docs_search, gets results, and summarizes them coherently. If it can't find the tools or the calls fail, your Uno MCP connection isn't working.
Build and run your app on any target. Then ask:
"Use App MCP to take a screenshot of the running app and get a visual tree snapshot of the current page."
uno_app_get_screenshot and uno_app_visualtree_snapshot and returns real data from your running app.This one exercises both MCPs in sequence with a real (small) feature: a button that opens a ContentDialog.
Ask the assistant:
"Using Uno MCP, look up the correct pattern for showing a ContentDialog in Uno Platform. Then propose how to add a Button labeled 'About' to [YourMainPage] that, when tapped, opens a ContentDialog with the title 'About This App' and a short message. Use MVUX—the button should bind to a command on the model. Show me all file changes."
Review the proposed changes. The assistant should produce:
- — A public method on your model (MVUX generates the command automatically)
-
—
XAML for the Button with
Command="{Binding ShowAbout}" - — The ContentDialog creation and display logic
Apply the changes. Rebuild and run. Then:
"Using App MCP, take a screenshot of the page. Confirm the About button exists in the visual tree. Then click the button and take another screenshot to confirm the ContentDialog appeared."
What You Just Did
You used both MCPs in sequence:
- Uno MCP gave the assistant accurate Uno Platform knowledge (ContentDialog patterns, MVUX command generation) so it proposed correct code instead of guessing
- You reviewed, applied, and built the change
- App MCP verified both the static result (button exists in visual tree) and the runtime behavior (dialog opens on click)
That third step is the important one. The assistant didn't just generate code and walk away—it confirmed the code works by interacting with the running app. It clicked the button. It saw the dialog.
The assistant itself reads your local project files—that's just how AI coding assistants work. What the MCPs add is Uno Platform expertise (Uno MCP) and runtime verification (App MCP). Without them, the assistant can read your code but doesn't know Uno Platform conventions and can't confirm what actually happens when a user taps something.
That's the entire mental model. Everything in Parts 2 and 3 builds on this loop.
Part 2 introduces the full Uno AI Dev Loop—a six-step repeatable workflow—and walks through two real scenarios: scaffolding a Settings page with MVUX and fixing a cross-platform layout bug. You'll get copy-paste prompt templates for each step.
Part 3 covers the hard cases (binding debugging, cross-platform parity verification), guardrails for when MCP is wasting your time, and daily habits to make this stick.
Subscribe to Our Blog 
Subscribe via RSS
Back to Top
