On February 22, 2004 I released version 1.0 of a little app called MCE Controller. At the time I was the Group Program Manager of Microsoft’s eHome division, the team building Windows Media Center. On the side I was helping build Premise Home Control Software. I lived at the intersection of media PCs and home automation, and those two worlds needed to talk to each other. Nothing did the job, so I wrote it myself: send MCE Controller a text string over TCP/IP or RS-232 and it becomes keystrokes, mouse input, or a launched app on the PC.
A year later I open sourced it. For 22 years right-minded home automation folks have used MCE Controller with Control4, Crestron, iRule, and everything in between to make Windows PCs do what they are told. It just kept working. (See MCE Controller v1.1 Released – and now open source and MCE Controller V2 Released.)
In 2026 there is a new kind of remote control: AI agents. An agent trying to drive Windows has exactly the problem a Home Assistant, Control4, or Crestron system had in 2004: It can’t press the keys or move the mouse, and it can’t see the screen.
So last week I released MCEC 3.0.
MCEC, the Model Context Environment Controller, is eyes, hands, and a safe front door for AI agents on Windows; and the same battle-tested remote control for smart-home systems it has always been.
Yes, the acronym still works. Tee-hee.
MCEC is a small, self-contained native Windows daemon that a computer-use model can mount, see through, and drive: capture a window as a PNG, read its UI Automation tree, find and wait for controls, launch apps, and actuate keyboard/mouse/window input, over the Model Context Protocol (MCP). The agent surface is opt-in and off by default; the 3.0 agent features are purely additive over the classic remote-control command surface (network and serial), which is unchanged.
The agent surface has three parts:
- Eyes: capture a screenshot of a window (or the foreground window) as a PNG.
- Hands: invoke any existing MCEC command (the actuation layer you already use).
- A front door: query/find windows and UI elements, wait for conditions, and drive all of the above over MCP (Model Context Protocol) or a tiny HTTP floor.
Handing an agent your mouse and keyboard should scare you. It scares me. So every agent capability in 3.0 is opt-in and OFF by default. There is a global emergency-stop hotkey that kills all agent activity instantly. And you can provision disposable, isolated sessions so an agent works in its own sandbox instead of your desktop. The details are in the Agent Safety guide.
To let a desktop agent app (an MCP client or desktop assistant) drive MCEC is to press the Provision new… button in the File ▸ Settings ▸ Agent dialog. MCEC mints a disposable copy of itself with agent commands enabled only inside that session; your installed Program Files copy stays untouched. See Agent Control for details.
And the damn thing actually works. Two proof points:
- I built much of 3.0 by having agents use MCEC to test MCEC. The dogfood recipe is in AGENTS.md.
- The Windows hero gif on WinPrint was produced by an agent using MCEC to launch WinPrint, drive its UI, and capture the screen. No human touched the mouse.
If you use MCEC for home automation, nothing changes. The classic TCP/IP and serial command surface is untouched; 3.0 is purely additive. Your Control4 driver from 2012 will keep on trucking.
Install it:
winget install Kindel.mcec
Docs are at tig.github.io/mcec and the source is at github.com/tig/mcec.
Try it and see. Let me know what you think in the comments, on X (@tigkindel), or come to my office hours.