You don't turn a sentence into a desktop automation script by asking a smarter LLM. You turn it into a script by forbidding the LLM from guessing.

Install Terminator's MCP server into a coding assistant you already use. Claude Code: `claude mcp add terminator "npx -y terminator-mcp-agent@latest"`. Cursor, VS Code, Windsurf accept the same npm command through their MCP config block. Then type the sentence. The assistant calls get_window_tree first because the system prompt makes it call get_window_tree first, derives selectors from the returned tree, and chains MCP tool calls (open_application, click_element, type_into_element, press_key, execute_sequence). The chain runs against the live desktop. To save it as a script for replay, write the same tool calls into a YAML file under a `steps:` key with `tool_name` and `arguments` and run it with `terminator mcp run workflow.yml`.

Two reasons that compound. First, the model has no observation of the live UI at write time. It writes `pyautogui.click(412, 78)` because it has seen that pattern in training data, not because the Save button is at (412, 78) on your screen. Second, even when the model is told to inspect the UI first, it has no enforcement mechanism: the next time you give it a different sentence it will silently regress to guessing. The Terminator MCP server moves the enforcement into the system prompt and the tool surface. The model is given a get_window_tree tool that returns the real tree and a system prompt that says, verbatim at prompt.rs line 21, `Always derive selectors strictly from the provided UI tree or DOM data; never guess or predict element attributes based on assumptions.` The selector engine then refuses non-deterministic forms (`#id` is rejected by convention in the docs) and accepts `role:Button && name:Save` style selectors that resolve against the live tree.

YAML or JSON. Either is a list of steps under a top-level `steps:` key. Each step has a `tool_name` (matches the MCP tool name, like `click_element`, `type_into_element`, `execute_sequence`, `open_application`, `press_key`), an `id` (string, used for jump targets and state references), and an `arguments` object whose shape is the same as the live MCP arguments. The test workflow at `crates/terminator-mcp-agent/tests/workflows/test_jump_if.yml` is the canonical example. Conditional jumps live under a `jumps:` array on each step, with `if:` (an expression that can reference prior step status or result fields), `to_id:` (the next step), and an optional `reason:` for logging. Replay loads the YAML, walks steps in order, evaluates jumps, and dispatches into the same MCP server that executed the live sentence.

`crates/terminator-mcp-agent/src/prompt.rs`. The function is `get_server_instructions()` and the entire returned string is the system prompt the MCP transport ships to the client. Read it once and the shape becomes obvious. The selector-discipline rule is at line 21. The batching rule for `execute_sequence` is at lines 38 to 53. The selector syntax block (role/name/text/id/nativeid prefixes, `&&` / `||` / `!` / `>>` combinators) is at lines 55 to 60. The full list of MCP tool names that may be used inside a sequence is injected at compile time via `env!("MCP_TOOLS")`. The prompt is checked into the repo and is the same one your local assistant receives when you install the agent via npx.

Sentence enters the assistant. Assistant reads system prompt, sees `get_window_tree` is the first move. Assistant calls `get_window_tree` with the target process. Server returns the structural tree of the foreground app: a flat list of UI elements with role, name, AutomationId, IsEnabled, bounds, and child relationships. Assistant picks a selector from the returned tree (literally copies role and name from one of the rows). Assistant calls `click_element` or `type_into_element` with that selector. Server resolves the selector against the live tree, performs the action through UI Automation, returns a ui_diff so the assistant can see what changed without taking another screenshot. Repeat until the sentence is satisfied. The trace is deterministic at the selector layer; the only place model judgement matters is choosing which row of the tree to use.

Yes, but the discipline matters. Two patterns. First, scope every selector to a process (`process:notepad >> role:Edit`). Without scoping, the same `role:Edit` could resolve into a different app's text field. Second, capture the tree once via `get_window_tree` and reuse its `name` and `AutomationId` values verbatim in the script. Selectors like `role:Button && name:Save` are stable across sessions because the UIA name comes from the app's resource file, not from runtime layout. The Terminator selector docs are explicit: `NEVER use #id selectors. They are non-deterministic across machines.` Save your script with `role:` plus `name:` plus `process:` scope and the same sentence will compile to the same script tomorrow and on a colleague's machine.

Because the unit of replay is not a function call, it is an MCP tool invocation, and the MCP server is the part that does the heavy lifting (selector resolution, retry, window management, screenshot capture, conditional jumps). A YAML or JSON sequence is a portable description of those invocations. It is language-agnostic by design. You can replay it from Rust, Node, Python, or any MCP client. You can pipe it into `terminator mcp run workflow.yml` from the @mediar-ai CLI. You can load it into the @mediar-ai/workflow TypeScript SDK and add Zod-typed input validation. You can hand-edit it without rebuilding anything. The Rust/Node bindings remain available for direct programmatic use; the YAML path is for the sentence-to-replay loop specifically.

Two layers of recovery. Static layer: a selector like `role:Button && name:Save` survives a layout reshuffle as long as the button still has the same name in the resource file. Surviving locales also works when the app exposes LocalizedRole. Dynamic layer: when a selector misses at replay, the MCP loop can dump the current `get_window_tree` to the LLM and ask for a patched selector for that one step. The rest of the script keeps running. This is the same loop the system prompt forces at write time, just invoked again at replay time on the one step that broke. A coordinate-based PyAutoGUI script has no equivalent recovery, which is the second reason the cold-LLM path produces brittle output: the script has no semantic identifier for the element it was clicking.

Windows is the primary platform with full feature support: UI Automation, the full selector grammar, the workflow recorder, the MCP server. macOS support exists at the core Rust level (the same selector strings resolve against the Accessibility API), and is the supported path for sentence-to-script on Mac. Linux uses AT-SPI2. The Node and Python SDKs ship Windows binaries today. If you are building a sentence-to-script flow that has to run cross-platform, the recommended shape is to author the script as YAML against the MCP server, then run it on whichever platform you target; the selector vocabulary normalizes across UIA, AX, and AT-SPI at the framework level.

Three pressures, none of which are 'we hope it does the right thing.' First, the system prompt repeats the rule near the top of the instructions block; models follow stated tool-use protocols when the framing is direct and short. Second, the selector engine itself rejects pixel-only and id-only selectors except as a last-resort `pos:x,y` prefix; if the model invents a selector it will see a resolution failure and self-correct. Third, every action tool defaults to capturing a UI diff (`ui_diff_before_after: true`) so the assistant sees what its selector actually touched. The combination collapses the failure mode where the model tells you the task succeeded while the screen is unchanged. It does not eliminate it, but it pushes the failure into a regime where retry-with-tree-dump fixes it.