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.

The Two MCPs

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)

What it is
A remotely hosted MCP server at https://mcp.platform.uno/v1.
What it does
Gives your AI assistant access to up-to-date Uno Platform documentation, best practices, and development conventions. It provides:
  • — 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)

When you use it
Planning a feature. Scaffolding new pages. Asking "what's the right way to do X in Uno Platform?" Getting the assistant to propose file changes that match your project's patterns.
Think of it as
Uno Platform's knowledge base, piped directly into your agent. Instead of guessing based on stale training data, it searches current docs and loads up-to-date development rules.

App MCP (Local)

What it is
A locally running MCP server started via dotnet dnx -y uno.devserver --mcp-app. It connects to your running application.
What it does
Gives your agent eyes and hands on your actual running app. Community license tools:
  • — 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 you use it
Something looks wrong at runtime. Verifying generated UI rendered correctly. Checking binding values. Confirming layout on a specific target. Debugging why a button does nothing when tapped.
Think of it as
Runtime truth. It doesn't guess what the UI looks like—it reads what's actually there.

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.

Getting Started

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.

Task 1: Confirm Uno MCP is connected 2 minutes

Ask your assistant:

"Search the Uno Platform docs for the recommended MVUX pattern for persisted settings. Summarize what you find."

What you're checking
The assistant calls 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.
What this is NOT checking
Uno MCP doesn't read your local project files. It provides Uno Platform documentation and development conventions. Your local project context comes from the assistant reading your files directly.
Uno MCP docs search result
Task 2: Confirm App MCP sees your running app 5 minutes

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."

What you're checking
The assistant calls uno_app_get_screenshot and uno_app_visualtree_snapshot and returns real data from your running app.
Task 3: Close the loop — propose, build, and verify 15 minutes

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're checking
The full loop—Uno MCP informed the proposal (correct ContentDialog pattern, MVUX command generation), you applied and built it, and App MCP verified both the static UI (button exists) and the runtime behavior (dialog appears on click). That's not just "does it compile"—it's "does it work."
Summary

What You Just Did

You used both MCPs in sequence:

  1. Uno MCP gave the assistant accurate Uno Platform knowledge (ContentDialog patterns, MVUX command generation) so it proposed correct code instead of guessing
  2. You reviewed, applied, and built the change
  3. 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.

Get Started Today

Ready to Build with AI-Assisted Workflows?

Sign up to Uno Platform Studio for free and set up Uno MCP and App MCP in minutes. Start building cross-platform apps with AI assistants that actually understand your code.

What's Next

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.

Links