Skip to main content

​
Overview

Demo-to-MCP lets you create a browser-automation MCP server by demonstrating a task instead of writing code. You record yourself doing a task in a browser, Arlet analyzes the recording into a reusable task playbook, and you get an MCP server that re-runs the task with Gemini 3.5 Flash computer use. It is the sibling of the chat-based Build flow:
  • From chat — describe an API-backed MCP in conversation; it deploys to Arlet’s cloud.
  • From recording — demonstrate a browser task; it runs locally in your own browser.
Because the task runs in your local browser, you use your own logged-in sessions — no credentials are ever stored on the server.

​
How it works

​
Prerequisites

  • Node.js >= 20
  • The Arlet CLI: npx arlet-cli
  • The arlet daemon running on the machine where the task should execute (npx arlet-cli up). The Gemini credential used for computer use is provided to your daemon by Arlet — you do not need to manage your own key.

​
1. Record a demo

Recording happens on your machine in a local browser. Run:
A browser opens. Perform the task you want to demonstrate — log in normally if needed (2FA and captchas work because it is your real browser). Press Enter in the terminal when done. The action trace and keyframes are uploaded to Arlet. Video and Playwright trace are not recorded by default — they are captured and uploaded only when you pass --video / --trace. Sensitive fields (passwords, one-time codes, card numbers) are masked in-page before anything leaves the browser. Use --no-upload to produce the recording bundle locally without uploading.

​
Start a recording from your AI client (MCP)

You can also start a recording from an MCP client (e.g. ChatGPT or Claude) instead of running arlet record yourself. Arlet’s own MCP server exposes two tools for this:
  • start_recording — creates a recording job and returns immediately with a job_id. If the arlet daemon is running on your machine, a browser opens for you to perform the demo. Inputs: optional name, start_url, and purpose.
  • get_recording_status — pass the job_id to poll progress. While you are still demonstrating (or the recording is being analyzed) it returns status: recording. Once done it returns the recording_id and a recording_mcp_path you can connect to in order to replay the task.
The demo itself is still performed by a human in the local browser — the AI client only starts and tracks the recording, it does not operate the browser. Your machine must be online with the arlet daemon running (npx arlet-cli up), and you stop the recording by closing the browser (the terminal-Enter stop is only for arlet record).

​
2. Analyze into a playbook

Open the Arlet dashboard → Build → switch to the From recording tab. Your recording appears in the list. Open it and click Analyze. Gemini turns the demo into a structured playbook:
  • Steps — the ordered actions of the task
  • Parameters — values that vary per run (these become the MCP tool inputs)
  • Login points — where authentication is required (handled by you at run time)
  • Success criteria — how completion is judged

​
3. Connect your MCP client

First make sure the arlet daemon is running, so tasks can execute on your machine:
In the Arlet dashboard, open the recording and switch to the Connect tab to get the recording’s MCP endpoint URL. Add that URL to your MCP client (e.g. Claude). On first connection the client authenticates with Arlet via OAuth. The server exposes two tools:
  • run_task — start the task. Its inputs are the playbook’s parameters. It returns immediately with a run_id; the task itself takes tens of seconds to minutes.
  • get_run_result — pass the run_id to fetch the result. While the task is still running it returns status: running — wait a few tens of seconds and call it again.
This asynchronous design keeps every call short, so the connection never depends on a single long-lived request and is not subject to client/proxy/server timeouts. When the agent calls run_task, the job is routed to your local daemon and runs in a visible browser on your machine, using your own logged-in sessions. When a login is required mid-task, execution pauses; you log in using the visible browser and it resumes automatically.

​
Security notes

  • The task runs in your local browser; no session cookies or credentials are stored server-side.
  • Sensitive form fields are masked at record time.
  • Login is performed interactively by each user at run time, not baked into the artifact.

​
Limitations

  • v1 targets browser tasks only (not full desktop control).
  • Gemini computer use may refuse some navigation phrasings via its safety guardrails; clear, playbook-derived instructions work best.
  • Login detection is heuristic; a visible (non-headless) browser is required so you can complete logins.