WebLoom

What WebLoom does

WebLoom exposes browser-control tools through an MCP stdio server. It drives a Chrome instance that the user starts with a CDP debug port, allowing an agent to work inside existing logged-in sessions rather than a separately managed browser. Named sessions can map to separate Chrome profiles, with account-specific logins and, on a server, separate proxy routes.

The server is aimed at sites where basic automation is unreliable. It includes alternate input paths for React-controlled fields, Lexical and Draft.js editors, several upload approaches, coordinate-based clicking, visual checks, and selected site workflows. It can also record successful actions to a local playbook and use site-specific Threads containing selectors, quirks, and recipes.

How it works

An MCP client starts server.py over stdio. WebLoom then connects to the Chrome instance already opened by the user through CDP; it does not install or launch Chrome and does not run as a background daemon.

Browser actions can be composed from navigation and tab tools, page reads, screenshots, waits, scrolling, clicks, fills, keyboard input, and uploads. More specialized tools provide fallback paths when a normal click or field setter fails. Network recording can capture requests for later inspection or replay, and recording workflows can be turned into reusable Thread data.

By default, local state is kept under ~/.webloom/, including Threads, logs, configuration, an installation identifier, and playbook.json. Telemetry is disabled by default. Thread update checks are enabled by default and can be disabled separately; the engine itself does not automatically update.

Setup and configuration

The recommended installation path is the installer at webloom.run/install. For a manual setup, clone the repository into ~/.webloom/engine, install the Python dependencies, and create ~/.webloom/threads and ~/.webloom/logs.

Add a stdio entry to the MCP client's configuration:

{
  "mcpServers": {
    "webloom": {
      "type": "stdio",
      "command": "python",
      "args": ["~/.webloom/engine/server.py"]
    }
  }
}

Restart the MCP client after adding the entry. WEBLOOM_TOOLS can reduce the visible tool set with profiles such as core, core,posting, core,network, or core,marketplace; individual tool names can also be added. WEBLOOM_AUTO_UPDATE=off disables automatic Thread update checks.

Tools and capabilities

• Navigate, inspect, screenshot, scroll, wait, list tabs, and open new tabs.
• Click by target or coordinates, invoke React handlers, and use visual checks or reCAPTCHA v2 solving.
• Fill ordinary fields and set content in React, Lexical, and Draft.js editors; type keyboard input.
• Upload files through browser, XHR, or replayed request paths.
• Record network activity, inspect captured requests, replay XHR requests, and inject code for new documents.
• Inspect React stores, dispatch Redux actions, and record or seed site-specific workflows.
• Create X posts and publish TikTok videos through the exposed posting tools.

The documented tool profiles can keep an MCP client's visible list shorter. Hidden tools remain callable for scripts and recipes.

Limitations and notes

Chrome must be started by the user with CDP access; WebLoom does not spawn or install it. The server only runs when invoked by the MCP client and does not provide its own scheduler or daemon.

The default data boundary is local. Page content, URLs, cookies, identity, post text, and similar browser data are not sent elsewhere by default. Optional Thread checks contact webloom.run, and anonymous {tool, ok, ms} statistics can be enabled explicitly through the telemetry command. The project is MIT licensed.