Clara Windows UI MCP
README.md
# Clara Windows UI MCP
Local-only MCP server for Windows UI automation oriented toward difficult targets such as game windows, legacy desktop apps, and surfaces that do not expose UI Automation reliably.
## Why this exists
The built-in computer-use flow is convenient, but it can struggle with windows that render through game engines or custom graphics pipelines. This MCP takes a lower-level path:
- enumerate and focus windows through `HWND`
- drive mouse and keyboard input through native Win32 APIs
- capture the desktop or a target window to PNG files
- expose the same behavior through MCP stdio and a small local HTTP API
## Current toolset
- `list_windows`
- `get_foreground_window`
- `focus_window`
- `capture_screen`
- `move_mouse`
- `click_mouse`
- `press_key`
- `type_text`
## Vision foundation
The `src/domain/vision` module defines the shared, consumer-facing vision contract:
- `SceneObservation` carries capture provenance, OCR, and detection results.
- `SceneEvent` leaves room for optional temporal change notifications.
- `VisionProfileRegistry` isolates examples, training-set references, and rules by `applicationId`.
Capture and detection implementations are intentionally not part of this foundation. Consumers should depend on the scene/event contract rather than detector internals.
## Vision service and tray
The native projects use the same safe session boundary as the Clara Cursor:
```text
ClaraVisionBroker Windows service -> local named pipe -> ClaraVisionTray user-session agent
```
- The broker persists the high-level observation state (`paused` or
`observing`) and relays it locally.
- The tray shows that state and lets the user start or pause observation.
- Neither component captures the desktop or performs automation. A future
session agent will connect the existing opt-in capture pipeline only after a
target selection and capture policy are defined.
Build `native/ClaraVisionBroker` and `native/ClaraVisionTray` in Release. Then
run `scripts/install-vision-service.cmd` from an elevated Command Prompt and
`scripts/install-vision-tray.cmd` from the interactive user session.
## Run
```powershell
npm.cmd install
npm.cmd run build
npm.cmd run start:stdio
```
For local diagnostics:
```powershell
npm.cmd run start:api
```
## Architecture choices
- run mode: `stdio`, `api`, or `both`
- deployment profile: local-only
- authentication: none
- storage: local file output only for captures
- organization: CQRS-style commands and queries with transport adapters
## Notes
- Screenshots are written under `captures/`.
- This first version avoids UIA on purpose so it remains useful for games and canvas-rendered apps.
- The next logical upgrade is target-aware matching by template image, pixel region, or OCR.
TDQS
B3.4/5.0
Scored across 8 tools
Disambiguation5/5
Each tool targets a distinct action: listing windows, getting foreground, focusing, capturing, mouse movement/click, and keyboard input. No overlap in purpose, unambiguous.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (list_windows, get_foreground_window, capture_screen, etc.) with snake_case, perfectly predictable.
Tool Count5/5
8 tools is well-scoped for a Windows UI automation server, covering window management, screen capture, and input simulation without bloat or thinning.
Completeness4/5
The set covers core UI automation workflows (window handling, mouse/keyboard input, screenshot). Minor gaps like reading window properties or mouse scroll are not critical but could be added.
Maintenance
ActivityMaintained
ResponsivenessNo issues