Feature Request: Support for automating Windows Server via RDP sessions

[ntphiep]

Currently, Windows-MCP runs as a local MCP server on the machine being automated. This works well for local Windows desktops, but there's no clear path for managing remote Windows Server instances accessed via RDP (Remote Desktop Protocol) — a very common scenario in enterprise/cloud environments (e.g., AWS EC2, Azure VMs, on-prem servers).

Describe the solution you'd like

A few possible approaches worth discussing:

1. Agent-side RDP session awareness — When an RDP session is active (e.g., via mstsc.exe), allow Windows-MCP to target the RDP window's virtual desktop, so Screenshot, Click, Type, etc. operate within that session.
2. Remote deployment model — Provide a guide or tooling to install and run Windows-MCP on the remote Windows Server, then expose it over a secure tunnel (e.g., SSH port-forwarding or the existing network transport mode), so the local AI agent connects to the remote instance.
3. First-class RDP transport — A dedicated transport that connects directly to an RDP endpoint (hostname + credentials), starts a session, and relays tool calls — similar to how some CI/CD tools drive headless RDP sessions.

Describe alternatives you've considered

• Running Windows-MCP on the server directly and connecting via the existing --transport streamable-http mode — but this requires manual setup and isn't documented for server environments.
• Using PowerShell remoting (WinRM) alongside Windows-MCP for the non-UI parts, and RDP only for the visual layer — but this is fragmented.

Additional context

Use cases this would unlock:

• Automated management/testing of Windows Server (IIS, AD, SQL Server, etc.)
• Cloud VM provisioning workflows driven by an AI agent
• QA automation against remote staging servers without needing physical access

Is there an existing workaround or a recommended architecture for this scenario?

[m13v]

the pain with RDP-driven automation is the AX tree doesn't survive the protocol. UIA queries inside the session are opaque to the local side because Windows-MCP is on the host just rendering pixels of mstsc.exe. you fall back to screenshot+OCR which is the exact flake you're trying to escape. option 1 has this problem regardless of how clever the targeting is. option 2 (run Windows-MCP on the server, tunnel over SSH or streamable-http) is the only path that gives real UIA queries on the actual app tree. WinRM for state checks, RDP only for the GUI smoke that genuinely needs pixels.