Browser MCP to desktop automation: you don't extend the server, you replace its dispatch root

The boundary is structural, not a missing feature

Read the source of any browser MCP and you'll find the same shape. Microsoft's playwright-mcp wraps a Playwright Browser; Chrome DevTools MCP wraps a CDP session and exposes 26 tools in 6 categories; browsermcp.io wraps a local Chrome through an extension; browser-use wraps a Playwright browser context; Browserbase wraps a remote browser. The tool registry is whatever methods the underlying object exposes. That is what makes them composable and easy to ship; it is also what makes them unable to leave the tab.

The Save dialog is not in the page DOM. The OAuth code in your desktop authenticator is not in the page DOM. Excel is not in the page DOM. The shell is not in the page DOM. None of those are reachable through a Page handle, so none of them are reachable through a browser MCP. You can bolt on a second MCP server, but two registries do not interleave inside one execute_sequence call, and the LLM has to plan twice.

The match block is the whole story

The fastest way to see what makes a desktop MCP different from a browser MCP is to read the dispatch function. In Terminator's server.rs, the dispatch_tool method is one Rust match tool_name at line 9953. Every tool the agent can call is one arm of that match.

// crates/terminator-mcp-agent/src/server.rs line 9953
// One Rust match block. The LLM picks any of these arms in one session.

let result = match tool_name {
    // Browser surface (overlaps with playwright-mcp / chrome-devtools-mcp)
    "navigate_browser"        => self.navigate_browser(...).await,
    "execute_browser_script"  => self.execute_browser_script(...).await,

    // Native OS surface (no browser MCP has these arms)
    "open_application"                  => self.open_application(...).await,
    "get_applications_and_windows_list" => self.get_apps(...).await,
    "get_window_tree"                   => self.get_window_tree(...).await,
    "click_element"                     => self.click_element(...).await,
    "type_into_element"                 => self.type_into_element(...).await,
    "press_key_global"                  => self.press_key_global(...).await,
    "mouse_drag"                        => self.mouse_drag(...).await,
    "run_command"                       => self.run_command(...).await,

    // Vision fallback in the same dispatch block
    "gemini_computer_use"     => self.gemini_computer_use(...).await,

    // Sequence runner that mixes any of the above
    "execute_sequence"        => self.execute_sequence(...).await,

    // ... around two dozen more arms (file ops, validation,
    // highlighting, scrolling, screenshots, etc.) ...
    _ => Err(McpError::internal_error("Unknown tool", ...)),
};

Around three dozen #[tool(...)] declarations live in server.rs; they all dispatch through that one match. The browser arms (navigate_browser, execute_browser_script) overlap with what a browser MCP gives you. The native arms (open_application, click_element, type_into_element, press_key_global, run_command) cannot exist in a browser MCP because their dispatch is bound to a Page object, not the OS.

What a unified dispatch looks like in flight

A real workflow that crosses the boundary: scrape a page, paste into Excel, save with a native dialog. The agent emits ten tool calls, the MCP server dispatches each one through the same match, and the browser extension and the OS accessibility tree do the work in their own lanes.

The MCP server is the only process the LLM talks to. Whether the next call lands on the browser extension at ws://127.0.0.1:17373 or on the Windows UIAutomation tree is decided inside the match. The agent does not know and does not have to.

What the YAML looks like when both surfaces are alive

The same shape as a Playwright MCP test, but with two extra kinds of step. Try this in Playwright MCP and the run halts at open_application: the tool is not in the registry. Try it in Terminator and every step routes through the same dispatch.

# crates/terminator-mcp-agent/examples/mixed.yml
# One MCP, one execute_sequence, two surfaces. The dispatch root is
# the OS; the browser is one of the arms.

steps:
  # Browser surface (would also work in Playwright MCP)
  - tool_name: navigate_browser
    arguments: { url: "<your internal orders URL>" }

  - id: rows
    tool_name: execute_browser_script
    arguments:
      script: |
        return Array.from(document.querySelectorAll("tr.order"))
          .map(r => [r.dataset.id, r.querySelector(".total").innerText].join("\t"))
          .join("\n");

  # Native surface (no browser MCP can reach this)
  - tool_name: open_application
    arguments: { path: "excel.exe" }

  - tool_name: type_into_element
    arguments:
      selector: "role:Window && name:Book1 - Excel"
      text_to_type: "${{rows_result}}"

  - tool_name: press_key_global
    arguments: { keys: "Ctrl+S" }

  # Native dialog, filled by selector
  - tool_name: type_into_element
    arguments:
      selector: "role:Edit && window:Save As && name:File name:"
      text_to_type: "q4-orders.xlsx"

  - tool_name: click_element
    arguments:
      selector: "role:Button && window:Save As && name:Save"

stop_on_error: true

The honest scope of each kind of MCP

If your agent will only ever live inside a tab, a browser MCP is the right tool and you do not need any of this. Playwright MCP is mature, Chrome DevTools MCP is the right pick for inspecting and debugging a real browser, Browser MCP is good for fully local Chrome control, browser-use for self-hosted agent loops. The argument here is only relevant if your workflow leaves the tab even once.

Install and verify the unified dispatch

The two tells that the dispatch root is the OS, not a tab: navigate_browser appears next to open_application in claude mcp list, and execute_sequence accepts a YAML that mixes both without a custom adapter.

# 1. Install Terminator's MCP server (Rust binary, behind npx)
claude mcp add terminator "npx -y terminator-mcp-agent@latest" -s user

# 2. Load the Chrome extension that gives the MCP server an eval channel
#    open chrome://extensions, toggle Developer Mode, "Load unpacked",
#    pick: terminator/crates/terminator/browser-extension/
#    (Manifest V3, name "Terminator Bridge", version 0.24.32)

# 3. Verify the dispatch is unified
claude mcp list
# terminator   stdio   ~3 dozen tools
# Includes navigate_browser AND open_application AND run_command
# in the same registry.

When to use this, and when not to

Use a desktop MCP when the agent has to cross from the page into a native window in a single workflow: download then open in Acrobat, scrape then paste into Excel, complete an OAuth flow that lands in a desktop authenticator, fill a system Save dialog, run a shell command between two browser steps. Use a browser MCP when the workflow stays in the tab, because the smaller registry is cheaper to plan against and the install is one binary.

The mistake is to bolt on a second MCP and assume the model will pick the right one. It will, sometimes; the failures show up at the boundary, where the model has to context-switch between two selector grammars and two state spaces, and they cost more than the migration to a unified dispatch would have.