Notion MCP server, but for the desktop app

Usually it means Notion's official hosted MCP server or one of the community wrappers around Notion's REST API (makenotion/notion-mcp-server, suekou/mcp-notion-server, Portkey's hosted version, Docker's MCP catalog entry). Those all let an LLM call Notion's cloud endpoints to search pages, read blocks, update databases, and create content. Terminator is a different kind of MCP server. It does not talk to Notion's cloud at all. It controls the Notion desktop client that is running on your machine, using Windows UI Automation. Instead of tools like retrieve_page or query_database, it exposes tools like click_element, type_into_element, get_window_tree, and execute_sequence. The LLM targets UI elements with selectors like window:Notion >> role:Button && name:Share. The two approaches are complementary: use the API server for structured reads and bulk writes; use the desktop server for UI actions that the API does not expose, or for anything that needs to happen inside the app the user is already signed into.

Four reasons, in order of how often they come up. First, the REST API does not cover every action. Keyboard-shortcut-only UI, sidebar reordering, template pickers, some view switches, and various in-app dialogs are only reachable through the UI. Second, no OAuth. The agent uses whatever session the Notion desktop app is already logged into. No integration grant, no per-workspace setup. Third, no rate limit. The Notion API is 3 requests per second average; UI Automation has no such limit, so bulk UI operations are bounded by how fast the app repaints. Fourth, cross-app workflows. The same MCP server that drives Notion also drives Chrome, Excel, Slack, Terminal, and any other app on the machine, from one dispatch_tool match block. If your automation spans Notion plus three other apps, you stay in one tool namespace instead of gluing four integrations together.

With a selector string. Terminator uses a prefix:value format with chainable combinators. Prefixes include role: (accessibility role like Button, Edit, Link), name: (accessible label, case-insensitive), text: (visible text, case-sensitive), id: (accessibility ID), nativeid: (Windows AutomationID or macOS AXIdentifier), classname:, visible:, pos:, and window: as a scope anchor. Combinators: && for AND, >> for descendant traversal, || for OR, ! for NOT, plus positional ones like rightof:, leftof:, above:, below:, near:, and .. to walk to the parent. A typical Notion selector looks like window:Notion >> role:Button && name:Share. That says "inside the window titled Notion, find a Button whose accessible name is Share." The same pattern works on every other Windows app, which is why Terminator calls itself Playwright-shaped for the whole desktop.

That the Notion desktop app is itself an MCP target, not via the Notion API but via Windows UI Automation. Terminator's MCP server exposes 31 tools from a single dispatch_tool match block in crates/terminator-mcp-agent/src/server.rs (line 9953). The relevant tools for Notion are get_window_tree (walk the app's accessibility tree and return JSON), click_element (invoke a button by selector), type_into_element (send characters through AX), wait_for_element (poll until something new renders), press_key (keyboard shortcuts), scroll_element (long sidebar, long page), and execute_sequence (YAML workflow that nests all of the above). The Notion homepage is already a test target in Terminator's Windows benchmark suite at crates/terminator/src/platforms/windows_benchmarks.rs. You can verify every tool and selector on this page by cloning mediar-ai/terminator and grepping the source.

Core automation is Windows-only today. The Terminator framework has macOS Accessibility API and Linux AT-SPI2 adapters in the tree (the selector engine, the MCP server shell, and the SDK bindings are cross-platform), but the stable production target is Windows, where UI Automation is the most complete. Notion's desktop client runs on Windows and macOS; for Windows, Terminator's MCP server is the full experience. On macOS, use the official Notion MCP server (API-backed) and keep an eye on Terminator's macOS progress, which is where cross-app UI automation via the AX API is headed.

One line: claude mcp add terminator "npx -y terminator-mcp-agent@latest" -s user. That registers the stdio server under Claude Code at user scope. For Cursor and VS Code, add a JSON block with command: npx and args: ["-y", "terminator-mcp-agent@latest"] to the MCP config. After that, Claude has the 31 tools available in its tool picker. With Notion already open, ask it to do something UI-shaped ("create a page titled April planning and share it with alice@example.com") and the LLM will chain get_applications_and_windows_list, open_application, get_window_tree, click_element, type_into_element, and click_element in one turn. For the full HTTP alternative, the terminator-mcp-agent binary also serves POST /mcp for JSON-RPC and GET /status for load balancer health.

Yes, for UI that the OS labels. Terminator's README reports >95% success rate and claims 100x the speed of screenshot-based agents like Claude computer use, ChatGPT Agents, BrowserBase, BrowserUse, and Perplexity Comet. The reason is straightforward: the accessibility tree is deterministic structured data the OS already maintains, so finding a button is a tree walk, not an LLM inference on a 2000x2000 image. For Notion specifically, the app's Electron UI exposes roles and names for nearly every interactive element, so role:Button && name:Share is a one-call resolve. The pixel fallback exists for the rare case where a widget is custom-drawn and thin on accessibility metadata; most of Notion is not that.

Yes, and it is often the right move. An LLM host like Claude Code can connect to multiple MCP servers at once; the tool namespace is flat but each tool is prefixed by its server. Use Notion's hosted MCP for bulk operations the API is good at: querying a database with filters, fetching page content, batch-updating properties. Use Terminator's MCP for UI actions the API does not expose or that need to happen in the user's real session: activating a specific view, dragging blocks, using a template picker, sharing through the UI, interacting with comments and reactions, and navigating the sidebar. The LLM decides per step which tool is cheaper. On a typical "create a new weekly review page from a template and share it with the team" task, the desktop MCP is often the shorter path because the template picker is UI-only.

With combinators. The || operator says "match either name," so role:Button && (name:Share || name:Sharing) covers both. The text: prefix matches visible text (case-sensitive) when the accessible name is empty or translated. When the element is stable but the name is noisy, anchor by nativeid: (Windows AutomationID) instead; Notion's electron builds expose these for many controls. Finally, positional combinators like rightof:, leftof:, above:, below:, near: let you pin to an element whose neighbors are stable even if its own name drifts. Example: click the button to the right of the "Pages" label: role:Button && rightof:role:Text && text:Pages. These patterns come straight from the selector cheatsheet in /docs/SELECTORS_CHEATSHEET.md in the Terminator repo.

Terminator has execute_sequence, an MCP tool whose arguments are a list of steps that nest the other 30 tools. A "open Notion, create a page, share it" workflow is: step 1 open_application with path Notion; step 2 wait_for_element for the Add a page button; step 3 click_element on that button; step 4 type_into_element into the title Edit; step 5 press_key Enter; step 6 click_element on Share. Each step has a selector and arguments, and the whole thing runs as one MCP call, one LLM turn, deterministically. If any step fails, the LLM gets the error on the next turn and can recover. This is what the README means when it says Terminator pre-trains workflows as deterministic code and only calls AI when recovery is needed. The point is you do not pay LLM latency for every click.