Skip to main content

Computer Use MCP Servers

Two servers expose the Computer Use Agent as delegation tools: the calling model hands over a whole natural-language task, and the agent drives the browser or desktop itself. They differ in where the work runs, which determines what you need to configure.
These are distinct from the MCP servers the agent consumes — Shopify, Mirakl, and Dsco — which let it call commerce APIs instead of clicking through a UI. See Engines and Commerce MCP.

Hosted server

A thin client for the hosted job API. Work executes on your dashboard workers, so this server just submits and polls.

Setup

Tools

Call stateset_cua_preview_task before trigger_task when an agent composed the instruction itself. Preview costs nothing and shows exactly what would execute.

Local server

Spawns the agent on the machine running the MCP host. No tenant API key, no account — but it drives your browser and desktop, so it ships its own guardrails.

Tools

Guardrails

Because tasks run locally with real desktop access, the server exposes policy, budget, and audit as first-class tools rather than configuration:
  • get_budget_status — a daily spend ceiling, checked before work starts.
  • list_engines — separates permitted by policy from available on this machine, so a policy restriction is visible rather than surfacing as a confusing failure.
  • get_audit_log — every task with its instruction, cost, outcome, and capability set.
  • doctor — run this first on a new machine; it reports a remedy per failure rather than just failing.
The local server drives the actual browser and desktop of the machine it runs on. Run doctor and review list_engines before pointing an agent at it, and keep the budget ceiling set — a looping agent otherwise spends real model credits against your desktop.

Choosing