What is iatlas-browser?

iatlas-browser turns your real Chrome session into a CLI, MCP server, and local HTTP runtime instead of forcing you to start from a separate clean browser.

How is it different from Playwright or Selenium?

It focuses on your existing logged-in browser session, so it can work with current cookies, tabs, page state, and user context without rebuilding authentication in a fresh browser.

Can I use it with MCP clients or through an API?

Yes. iatlas-browser can run as an MCP server for tools like Cursor or Claude Desktop, and its local daemon also exposes an HTTP API for status and browser commands.

Authenticated browser automation for AI agents, engineers, and MCP clients

Use your logged-in Chrome as an API.

iatlas-browser turns the browser session you already trust into a CLI, an MCP server, and a local HTTP runtime. It is built for the hard part most browser tools avoid: authenticated websites, live tabs, real cookies, and dynamic page state. miaoda.vip remains the narrower hosted API layer for public, server-safe work only.

No cookie export required CLI + MCP + local HTTP on one runtime Direct CDP refs persist across commands Hosted API only for server-safe tasks

Download install.sh Browse site adapters Open API docs Download extension zip GitHub

3-minute first win

curl -fsSL https://miaoda.vip/install.sh | bash
iatlas-browser daemon
iatlas-browser doctor
iatlas-browser snapshot -i

Installs into ~/.iatlas-browser/src and builds the local runtime
Creates the CLI, daemon, MCP entrypoint, extension bundle, and setup artifacts
Detects Chrome, Canary, Chromium, Brave, and Arc for faster direct-CDP startup
Gets you to the first authenticated browser snapshot without rebuilding login state

Real-session Operate on the same browser context, cookies, tabs, and page state you already use.

Unified runtime Use one local engine from terminal scripts, MCP clients, and local HTTP integrations.

Clear boundary Keep browser-sensitive work local and use the hosted layer only for public-safe requests.

Fallback that still works Direct CDP can now persist snapshot refs and reuse them for click, fill, type, hover, and text reads.

Local runtime upgrade

The extensionless path is now usable for common snapshot-driven flows.

Remote debugging mode is no longer just for opening a page and taking a read-only snapshot. The daemon now keeps direct-CDP refs across commands, which makes the fallback path viable for common ref-based actions.

Persistent direct refs

Run snapshot once, then reuse those refs later for click, hover, fill, type, and get text.

Broader browser detection

iatlas-browser doctor now detects Chrome, Beta, Dev, Canary, Chromium, Brave, and Arc, then prints launch hints for remote debugging.

Better MCP continuity

Common MCP browser flows keep moving even when you temporarily fall back to direct CDP instead of the extension path.

Why it matters

Most automation starts from a clean browser. iatlas-browser starts from yours.

That difference is the whole product. It changes how fast users reach a first win on authenticated websites, internal dashboards, social platforms, and browser-native agent workflows.

Task	Fresh headless browser	iatlas-browser
Use a site you are already logged into	Recreate auth, cookies, and browser state in a separate environment	Reuse the current session directly through your existing Chrome
Debug a broken flow on a real page	Switch between your real browser and an isolated automation browser	Inspect and act inside the same browser context you already trust
Give an MCP agent browser access	Expose a separate sandbox that may not match the user session	Expose the live local browser through one runtime shared by CLI, MCP, and HTTP
Run server-safe public fetches	Often overuse browser automation for work that should be remote	Route those jobs to the smaller hosted API subset on `miaoda.vip`

Product boundary

Start with the local runtime. Use the hosted layer only when the task is server-safe.

Local core mode

This is the real product center: your browser, your login state, your tabs, your page context, and the full CLI + MCP + site adapter model. If the task depends on authenticated state or live browser context, this is the mode that matters.

Best for authenticated pages, live tabs, and session-sensitive actions.
Runs through the local daemon, browser extension, CLI, and MCP entrypoint.
Covers the commands and adapters that need a real user browser context.

Hosted subset mode

miaoda.vip adds a public API service for browser-open requests and a curated subset of hosted adapters. It is intentionally smaller than the local runtime and should be understood as an extension layer, not as a replacement for the core engine.

Useful for public metadata fetches, catalog lookup, and hosted read-only adapters.
Runs on the remote server with API keys and daily usage accounting.
Does not aim to mirror the full browser-state-sensitive local experience.

Browser automation Chrome automation MCP browser server AI agent browser tool Authenticated browser API Local browser API Hosted site adapters

How It Works

The system is a tight loop, not a pile of disconnected tools

The original strength of this project is not just command coverage. It is the way a real browser session, a local daemon, an extension bridge, and MCP access all fit into one execution model.

The extension bridges into the browser you are already using

That removes the usual friction of rebuilding cookies, page state, and account context from scratch.

The local daemon turns browser actions into a stable control surface

CLI commands, MCP tools, and local HTTP calls all land on the same runtime instead of diverging.

The `site` adapter model gives each platform a reusable command interface

That keeps platform-specific logic modular while preserving one common way to discover and run tools.

The hosted layer only takes the subset that can run safely on a remote server

Public API access expands reach, but the full authenticated browser workflow still stays local by design.

Why teams end up needing this

Many teams do not actually need "a browser." They need the current logged-in browser session they already use for dashboards, internal tools, social platforms, and web apps with dynamic page state.

What changes when you use it

Standard automation tools often start from a clean browser. iatlas-browser starts from the browser you already trust, then exposes it as CLI commands, an MCP server, and a local HTTP interface.

Who gets value fastest

AI agent builders, automation engineers, browser tool developers, and anyone who needs a practical way to interact with authenticated websites from scripts or agent runtimes.

Open API access

Create an API key with email and start immediately

The hosted interface is available on https://miaoda.vip/v1/. Each email-bound API key gets 1000 open requests per day. This is the hosted subset layer, useful for public API-style access, while the full real-browser workflow stays local.

Quota and endpoint model

Auth: `Authorization: Bearer <apiKey>` or `X-API-Key`
Quota: 1000 requests per email per day
Endpoints: `POST /v1/register`, `GET /v1/usage`, `POST /v1/open`, `GET /v1/sites/hosted`, `POST /v1/sites/run`
Open target: public `http` and `https` URLs

curl -s https://miaoda.vip/v1/open \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com","mode":"metadata"}'

Hosted API Lab

One place to test both hosted API surfaces

This lab keeps the hosted subset compact and understandable. Use it for public URL fetches and remote-safe hosted adapters. Anything that depends on your real tabs, login state, or browser context still belongs to the local runtime.

Create an API key above or paste one here. The lab shares the same stored key across both hosted tools.

Presets

Input: public http or https URL only
Modes: metadata, text, html
Auth: shared API key from this lab

Recent examples

Run a hosted request to pin reusable examples here.

Live response

Choose a hosted tool, load a preset, and run a live request.

Install and first run

Get from zero to first browser command quickly

1. Install the tool

curl -fsSL https://miaoda.vip/install.sh | bash

2. Load the Chrome extension

chrome://extensions/

Load the unpacked folder at ~/.iatlas-browser/extension.

3. Start the local runtime

iatlas-browser daemon
iatlas-browser doctor

4. Use browser commands

iatlas-browser open https://example.com
iatlas-browser snapshot -i
iatlas-browser get title

Core explanation

What iatlas-browser actually does

Terminal browser automation

Run commands such as open, snapshot, click, fill, network, and fetch against the current browser context.

iatlas-browser open https://app.example.com
iatlas-browser snapshot -i
iatlas-browser click @3

MCP browser server

Expose the browser to agent frameworks and code assistants through MCP. This is useful for Cursor, Claude Desktop, and other MCP-compatible tooling.

iatlas-browser mcp-config cursor
iatlas-browser --mcp

Download Cursor MCP snippet

Local browser API

The daemon serves a local HTTP API on 127.0.0.1:19824, making it easy to orchestrate browser tasks from shell scripts or external applications.

curl -s http://127.0.0.1:19824/status
curl -s http://127.0.0.1:19824/command \
  -H "Content-Type: application/json" \
  -d '{"id":"demo-open","action":"open","url":"https://example.com"}'

Download API examples

Authenticated website access

This is the practical difference: iatlas-browser can reuse your current website session and page state. That makes it useful for internal dashboards, admin panels, and websites with complex browser-side flows.

Interactive Demo

Switch between real usage paths before you install

These are not abstract examples. They match the actual shapes users hit first when they start with local CLI automation, MCP integration, local HTTP control, or the hosted API subset.

Local CLI for the browser you already control

Use direct terminal commands when you want the fastest path into your current authenticated browser session.

Good for debugging, navigation, snapshots, clicks, and iterative browser work.
Runs through your local daemon and extension against your live Chrome session.
Best starting point when the job depends on existing tabs or login state.

Example request

iatlas-browser open https://app.example.com
iatlas-browser snapshot -i
iatlas-browser click @3

Get install.sh

Decision guide

Choose the right entry point in under a minute

If the task depends on your real login state, personal tabs, or dynamic page context, install the local runtime. If the task is a public fetch or a hosted read-only adapter call, use the Open API. Keeping that boundary clear prevents most integration mistakes.

Fast routing

Need your own login session: use local CLI, daemon, or MCP.
Need remote public fetches: use the hosted Open API.
Need site command discovery: browse the adapter catalog.
Need agent integration: generate MCP config and connect to the local runtime.

Use cases

Common scenarios

AI agents that need a browser

Give an agent access to a real browser instead of faking API responses or scraping stale HTML.

Automation behind login

Work with SaaS admin consoles, internal tools, and authenticated pages that break in fresh sessions.

Reverse engineering websites

Inspect requests, console logs, page snapshots, and fetch calls while you are already logged in.

Comparison

How it differs from standard browser automation

Capability	Fresh headless browser	iatlas-browser
Existing login session	Usually needs to be recreated	Uses your current browser session
Page state and live tabs	Separate environment	Works with the browser you already use
MCP integration	Needs custom glue	Built in
Local HTTP control	Custom service required	Built in daemon API