Splitting state from execution means the model commits to a plan against a page it has actually read, rather than firing a click and hoping. That is a small surface — this is a hackathon project and it shows in the setup, which wants macOS, a specific Python, and Chrome closed before you begin. Recordings land under ./tmp/recordings, which is the fastest way to see what a run actually did.
A browser automation server built on Browser-Use. It drives Google Chrome and splits the loop in two — one call to see where things stand, another to act on it.
- `get_planner_state` returns the current browser state and planning context
- `execute_actions` runs the actions you planned in the browser
- Interactive element detection and manipulation on the live page
- Configurable browser contexts, with session recordings written to ./tmp/recordings
macOS, Python 3.12 or higher, the uv package manager, and Google Chrome — closed before you start a task, since the server drives your installed browser. Clone the repository, `uv venv` and `uv sync`, then point your client at `browser-use.py` with `uv --directory <path> run`. It runs non-headless by default at a 1280x1100 window, which is intentional for development.
One command — npx -y @smithery/cli install @ashley-ha/mcp-manus --client claude
