
DesktopManager Windows Verification
io.github.EvotecITPublished by GitHub account EvotecITv0.2.3Updated Oct 25, 2026
Inspect and verify Windows x64 desktop apps through a local, read-only-by-default MCP server.
Overview
A local Windows x64 MCP server that lets an assistant inspect and verify desktop apps, monitors, windows, audio, power, radios and devices, read-only by default
- What you can do
- Inspect monitors, display devices, wallpapers, brightness, resolution and orientation, and capture desktop screenshots from all monitors, one monitor or a region. Enumerate and control windows: position, size, state, topmost, layouts, keep-alive sessions and virtual-desktop membership. Read and change audio endpoints, volume, mute and default roles, plus power and interactive-session state. Inspect and apply workstation profiles, personalization snapshots and taskbar settings. List saved Wi-Fi profiles, radios, Plug and Play devices and Driver Store packages, with explicit enable/disable or connect actions.
- When to use it
- Useful when an agent needs to check or verify the state of a Windows desktop — display layout, window placement, audio, power or devices — and only change it deliberately. Suited to operator and QA workflows on a Windows x64 machine rather than general cross-platform automation.
- Requirements
- Runs as a local process on Windows x64 desktop machines, distributed as an mcpb package over stdio. No authentication, environment variables or headers are declared. The README notes some actions need confirmation or elevation, and experimental features require an explicit allow-experimental flag.
Installation
In SourceWeft
- Open DesktopManager Windows Verification in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
DesktopManager - C# Library and PowerShell Module
DesktopManager is a Windows desktop automation toolkit available as a .NET library, PowerShell module, CLI, MCP server, and tray app.
The .NET library also exposes PortableDesktopService for current-user wallpaper, display discovery,
and session diagnostics on Windows, macOS, GNOME, and KDE Plasma. Each adapter reports its capabilities;
the window automation, tray app, CLI, and existing PowerShell commands retain their Windows scope.
See Portable desktop integration for usage and platform limits.
[nuget downloads] [nuget version]
You can also download it from PowerShell Gallery
[PowerShell Gallery Version] [PowerShell Gallery Preview Version] [PowerShell Gallery Downloads]
[PowerShell Gallery Platform] [GitHub top language] [GitHub code size in bytes] [GitHub license]
If you would like to contact me you can do so via Twitter or LinkedIn.
[Twitter Follow] [Blog evotec.xyz] [LinkedIn pklys] [Discord] [Threads @PrzemyslawKlys]
What it's all about
[Image]DesktopManager provides one shared Windows automation core through five surfaces:
- C# library for .NET applications and services
- PowerShell module for scripts and operator workflows
- CLI executable for terminal and JSON automation
- MCP server for inspect-first agent automation
- Windows tray app for daily hotkeys and monitor actions
It has following features:
- Get information about monitors
- Get information about display devices
- Get information about wallpapers
- Set wallpapers
- Get/Set desktop background color
- Get/Set monitor position
- Get/Set window position
- Get/Set window state (minimize, maximize, restore)
- Capture desktop screenshots from all monitors, a single monitor or a custom region
- Manage monitor brightness
- Start/Stop/Advance wallpaper slideshows
- Track wallpaper history
- Adjust monitor resolution and orientation
- Move monitors around the virtual desktop
- Save and restore window layouts
- Snap or move windows between monitors
- Subscribe to resolution, orientation or display changes
- Keep inactive windows awake using periodic input
- Manage keep-alive sessions for windows
- Save and restore cohesive workstation profiles across displays, audio, personalization, and taskbars
- Enumerate Core Audio render/capture endpoints, change volume and mute, set default roles, and observe endpoint changes
- Inspect power and interactive-session state; lock, sign out, sleep, hibernate, or hold a bounded keep-awake lease
- Capture and restore personalization snapshots and configure taskbar visibility, position, and auto-hide
- Enumerate, observe, and explicitly enable or disable Wi-Fi, Bluetooth, mobile broadband, and FM radios through the supported Windows radio API
- List saved Windows Wi-Fi profiles and connect an exact saved profile without scanning nearby networks or exposing credentials
- Inspect a window's virtual desktop and move it to a known desktop through the public Windows virtual-desktop API
- Inspect and manage Plug and Play devices and Driver Store packages through documented native Windows APIs
Wallpaper consumers
Applications such as PowerBGInfo can read monitor geometry, display scale and the signed-in session user directly from the library:
Snapshots contain physical pixel bounds and per-monitor DPI even when the caller is not DPI aware. The calling thread's DPI context is restored. Indexes describe the current display topology; read them again after docking or reconnecting. Missing wallpaper device paths on session hosts are retained.
Monitors.SetLogonWallpaperWithResult(imagePath) sets the current account's lock screen through
Windows Runtime on .NET Framework, modern .NET and netstandard consumers. The result reports success,
the mechanism used and any failure. Machine policy fallback requires an explicit
allowPolicyFallback: true and elevation. The existing SetLogonWallpaper method keeps its automatic
policy fallback. See Wallpaper consumer APIs for examples, OS requirements,
policy limits and session deployment behavior.
Desktop state and controls
The workstation profile is the high-level entrypoint when you want to move between repeatable setups. It captures connected monitor modes and placement, monitor wallpaper and supported brightness/HDR state, active audio endpoint state and default roles, personalization, and taskbars. Applying a profile matches monitors by stable identity, stages display changes together, and rolls back the selected sections when a required step fails. Machine-wide personalization policies are captured but only restored when explicitly requested.
The same capabilities are available from the CLI:
Radio control has two deliberately separate APIs. RadioService and the normal radio list / radio set commands use the supported Windows.Devices.Radios contract for individual radios. Global airplane mode uses an undocumented Windows shell COM contract, so it lives under ExperimentalAirplaneModeService and requires --experimental in the CLI, -Experimental in PowerShell, or --allow-experimental in MCP.
Wi-Fi profile connection is separate from radio control. WifiProfileService, Get-DesktopWifiProfile, and desktopmanager wifi profiles enumerate only profiles already stored by Windows. Connecting an exact profile uses the Native Wi-Fi profile API and ACM completion notifications; it does not scan nearby networks, return BSSIDs, expose profile XML or credentials, or query location-sensitive current-connection details. Windows still requires location consent for nearby-network scanning and related Wi-Fi information APIs. See Changes to API behavior for Wi-Fi access and location.
VirtualDesktopService exposes only the public Windows operations: check whether a top-level window is on the current desktop, get its desktop ID, and move it to a known desktop ID. Desktop enumeration, creation, renaming, switching, and removal are intentionally not presented as supported APIs.
Additional operator-focused docs for the newer CLI and MCP surfaces:
- Docs/DesktopManager.Cli.md
- Docs/DesktopManager.Mcp.md
- Docs/DesktopManager.Architecture.md
- Docs/DesktopManager.DesktopState.md
- Docs/DesktopManager.DeviceManagement.md
- Docs/DesktopManager.AutomationBasics.md
- Docs/DesktopManager.Plugin.md
- .agents/skills/desktopmanager-operator/SKILL.md
- .agents/skills/desktopmanager-build/SKILL.md
Which Surface Should You Use?
How It Fits Together
DesktopManager now has one shared core and several operator-facing surfaces on top of it.
If you want the fuller component and request-flow diagrams, see Docs/DesktopManager.Architecture.md.
The practical way to think about this:
- use the library when DesktopManager is part of your own application
- use PowerShell when you want scriptable admin/operator automation
- use the CLI when you want a human-friendly or JSON-friendly command surface
- use MCP when an agent should inspect first and mutate only through an explicit server session
Common Entry Points
Request Flow at a Glance
The important part is that CLI, MCP, and PowerShell are meant to stay aligned by reusing the same shared C# behavior rather than inventing separate desktop logic in each surface.
Available PowerShell Cmdlets
Cmdlet to C# method map
The table below shows the most relevant API methods behind each PowerShell cmdlet.
Installation
For using in PowerShell you can install it from PowerShell Gallery
For the daily Windows tray app, use the DesktopManager MSI release artifact when available. The installer creates a Start Menu shortcut, and the app's Startup toggle registers the current user for minimized tray startup.
From source, the app and MSI are built through PowerForge:
Verified mutation examples
When you want more than "the call did not throw", prefer -Verify together with -PassThru so the cmdlet returns the observed postcondition.
Verification behavior is action-aware:
- window mutations verify geometry, state, topmost, close, or foreground conditions when those postconditions are meaningful
Set-DesktopControlText -Verifyverifies the observed text/value when the control can be re-queriedSet-DesktopControlCheck -Verifyverifies the observed check state- control click/key actions return honest presence and foreground evidence when exact semantic verification would be misleading
Testing notes
UI-impacting tests are opt-in to avoid opening windows or changing the desktop during local development. Use the environment variables below to control behavior:
RUN_UI_TESTS=true(orDESKTOPMANAGER_RUN_UI_TESTS=true) enables the top-level UI test pack.RUN_OWNED_WINDOW_UI_TESTS=true(orDESKTOPMANAGER_RUN_OWNED_WINDOW_UI_TESTS=true) enables owned-window UI tests that use repo-created harness windows.RUN_DESTRUCTIVE_UI_TESTS=true(orDESKTOPMANAGER_RUN_DESTRUCTIVE_UI_TESTS=true) enables owned-window mutation tests such as move, resize, hide, snap, and transparency changes against repo-created harness windows.RUN_FOREGROUND_UI_TESTS=true(orDESKTOPMANAGER_RUN_FOREGROUND_UI_TESTS=true) enables tests that intentionally steal foreground focus, even when they only target repo-created harness windows.RUN_SYSTEM_UI_TESTS=true(orDESKTOPMANAGER_RUN_SYSTEM_UI_TESTS=true) enables system-wide desktop changes such as wallpapers, brightness, resolution, and other monitor-level mutations that can affect your current session.RUN_EXTERNAL_UI_TESTS=true(orDESKTOPMANAGER_RUN_EXTERNAL_UI_TESTS=true) enables live external-application UI tests and MCP end-to-end harnesses that launch real desktop apps.RUN_EXPERIMENTAL_UI_TESTS=true(orDESKTOPMANAGER_RUN_EXPERIMENTAL_UI_TESTS=true) enables experimental live UI harnesses that are useful for manual validation but are not part of the stable regression pack.SKIP_UI_TESTS=true(orDESKTOPMANAGER_SKIP_UI_TESTS=true) forces UI tests to skip, even if enabled elsewhere.
Owned WinForms fixtures show without activation. Tests that explicitly activate a window or depend on foreground focus also require the foreground gate. Keep RUN_FOREGROUND_UI_TESTS and DESKTOPMANAGER_RUN_FOREGROUND_UI_TESTS disabled while using the desktop; enable that slice only during a dedicated interactive run.
The gates compose intentionally:
When the hosted-session or experimental live harnesses skip because focus or discoverability never stabilize, they now leave structured diagnostics and artifacts rather than failing silently. See Docs/Build.Runbook.md for the hosted-session artifact flow and gate guidance.
Usage
Example in C#
The DesktopManager.Example project contains additional examples. Its default mode is read-only; mutation demos require the explicit --run-mutations option.
Example in C# - Getting/Setting Window Position
Platform notes
When retrieving a window's style the library uses a helper method that calls
GetWindowLong on 32-bit processes and GetWindowLongPtr on 64-bit ones. The
method returns an IntPtr, so callers should convert the value to the
appropriate numeric type.
Example in PowerShell - Getting Monitor Information
Example in PowerShell - Wallpaper Slideshow
Example in PowerShell - Setting Monitor Position
Example in PowerShell - Getting/Setting Window Position
Example in PowerShell - Activating and Setting Window Top-Most
Example in C# - Activating and Setting Window Top-Most
Use Register-DesktopOrientationEvent or Register-DesktopResolutionEvent to handle orientation or resolution changes individually.
Example in C# - Monitoring Display Changes
Applications can subscribe to the MonitorWatcher.DisplaySettingsChanged event.
Example in PowerShell - Saving and Restoring Window Layout
For optional virtual desktop assignments, pins, Explorer folders and explicit per-desktop wallpaper restoration, see Workspace recovery.
Example in C# - Saving and Restoring Window Layout
Layout restoration uses each live window at most once and skips ambiguous or missing targets. Saved layouts include process and native class names so a restarted application can be matched without relying only on its title. Legacy files retain exact process-ID/title matching; title-only and process-only fallback are disabled. Use PlanLayout to inspect matches and ApplyLayout to obtain per-window outcomes:
Examples in PowerShell - Window Keep-Alive Cmdlets
Examples in C# - Window Keep-Alive
C# API Highlights
DesktopManager ships as a .NET library targeting net472, netstandard2.0, net8.0-windows10.0.19041.0, and net10.0-windows10.0.19041.0. The main entry points are:
Monitorsfor monitor enumeration, wallpaper management, brightness, resolution, orientation and slideshow control.WindowManagerfor window enumeration, positioning, resizing and layout persistence.MonitorWatcherto receive events when display settings change.ScreenshotServiceto capture the desktop or custom regions.WorkstationProfileServiceandWorkstationProfileStorefor cohesive named workstation state.AudioServiceandAudioEndpointWatcherfor Core Audio endpoints, default roles, volume, mute, and changes.SystemPowerService,DesktopSessionService, andDesktopSessionWatcherfor power and session state/actions.PersonalizationService,PersonalizationStateStore, andTaskbarServicefor reversible user settings and taskbars.RadioServicefor supported per-radio operations andExperimentalAirplaneModeServicefor the separately acknowledged undocumented global switch.WifiProfileServicefor saved-profile inventory and exact profile connection without nearby-network scanning.VirtualDesktopServicefor the supported window-to-desktop operations.
Input, waits, and provider health
TypeText and PasteText insert at an editable control's current selection. They do not replace its whole value to repair an unexpected result. Background text delivery prefers the target's focused editor and rejects multiple eligible editors when none is focused. Use WindowControlService.SetText when replacement is intended. Paste, native clicks, and character messages are delivered once. InputRetryCount applies only when SendInput confirms zero input was delivered. A NativeOperationOutcomeUnknownException means the target may already have changed; observe its state before deciding whether to retry. Requested focus and clipboard-text restoration also runs when delivery fails.
Asynchronous waits support cancellation on every library target. A zero timeout waits indefinitely until a match appears or cancellation is requested:
UI Automation uses a separate STA worker per target process, with at most 16 workers and 64 queued operations per worker. Each worker permits up to 64 active event subscriptions with reserved cleanup capacity, so a full operation queue cannot lose cleanup. One blocked provider therefore leaves other processes available while capacity remains. In-flight native calls cannot be safely canceled or replayed and retain their worker until they return. DesktopAutomationDiagnostics.GetUiAutomationHealth() reports pending work and blocked calls without contacting the providers. Worker shutdown is bounded, and new work fails when the worker or queue limit is reached.
Window capture provenance
CaptureWindow retains its desktop fallback behavior. CaptureWindowDetailed defaults to strict window capture and records the backend, actual screen bounds, dark-pixel observation, and fallback reason. A dark image can be legitimate; strict mode retains those pixels. Desktop fallback may contain a covering application's pixels.
Pass new WindowCaptureOptions { AllowDesktopFallback = true } to opt into visible-desktop fallback. DesktopAutomationService capture objects and CLI/MCP screenshot results also expose the capture backend and fallback reason. Sparse dark-image and visual-difference sampling reads locked pixels directly, avoiding full-image managed copies; template matching retains its dense pixel buffer.
Display requests requiring a restart
SetMonitorDisplayModeDetailed returns RestartRequired when Windows accepts a display request that needs a system restart. The existing void SetMonitorDisplayMode method throws DisplayRestartRequiredException for that outcome. Workstation profile results report Succeeded = false and RestartRequired = true for this request. PowerShell and the tray app display a warning; CLI JSON and MCP results preserve the restart requirement. No API restarts Windows automatically.
Source: README.MD at commit 948a584
Tools
0Version history
3- v0.2.3LatestOct 25, 2026
- v0.2.2Oct 23, 2026
- v0.2.1Oct 15, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts