local-browser

When to use

Reach for this skill whenever the task needs to act AS THE USER in a
web context. The hallmark is: an unauthenticated browser can't do this
because the page requires their cookies/session.

• "Post this to LinkedIn / Twitter / Reddit" — needs their logged-in
  session.
• "Check my Gmail / Slack / Linear for X" — same.
• "Pull this from behind SSO."
• "Place this order on Amazon / book this flight" — payment + saved
  cards + addresses.
• "Comment on this PR / file this Jira ticket" — authored as them.

If the page is public and unauthenticated, prefer a regular fetch /
plain scraping tool — driving a real browser is overkill and the
cookies are sensitive.

What it is

The local-browser plugin (@agentproto/plugin-local-browser) is a
one-time setup that:

1. Clones one of the user's existing Chrome profiles into
   ~/.agentproto/chrome-profile/ (cookies + extensions + logins
   transfer).
2. Installs chrome-devtools-mcp into ~/.agentproto/chrome-mcp/.
3. Registers it in ~/.agentproto/imported-mcps.json so the
   agentproto daemon proxies all 29 browser tools through /mcp to
   every tunnel-connected client.

The daemon spawns Chrome on demand against the cloned profile, so the
user's daily Chrome keeps running undisturbed.

How to call it

Tools surface under the alias local-browser. From an agentproto
MCP-proxy client they're invoked via the daemon's meta-tools:

// list everything available
mcp_imported_tool_list({ alias: "local-browser" })

// drive the browser
mcp_imported_call({
  alias: "local-browser",
  tool: "navigate_page",
  arguments: { url: "https://news.ycombinator.com" }
})

The 29 tools fall into these buckets:

What you want	Tool(s)
Open / switch pages	new_page, navigate_page, select_page, list_pages, close_page
See the page	take_snapshot (AX tree), take_screenshot, list_console_messages
Click / type / fill	click, type_text, fill, fill_form, press_key, hover, drag
Wait for something	wait_for
Run JS	evaluate_script
Network inspection	list_network_requests, get_network_request
Perf / Lighthouse	performance_start_trace, performance_stop_trace, lighthouse_audit
Files / dialogs / viewport	upload_file, handle_dialog, resize_page, emulate

A typical flow:

1. navigate_page to the target URL.
2. take_snapshot — returns an AX tree where each element has a
   uid.
3. Pass that uid to click / fill / etc. (do NOT pass CSS
   selectors).
4. wait_for if the next step depends on a network response or DOM
   change.
5. take_screenshot if you need to show the user what happened.

How to know it's installed

If mcp_imported_status doesn't list a local-browser import, the
user hasn't set the plugin up yet. Suggest:

npx -y -p @agentproto/plugin-local-browser agentproto-browser setup

Then the user restarts the daemon (~/.agentproto/start-daemon-prod.sh)
and the tools appear on the next mcp_imported_status.

Safety rails

The plugin drives a Chrome signed into the user's accounts. That means:

• Don't speculatively click things. Each call may post, pay, send,
  or delete with the user's identity. Always state what you're about
  to do and get explicit confirmation for irreversible actions.
• Don't run evaluate_script with anything that could exfiltrate
  (document.cookie, localStorage dumps, etc.) without an extremely
  clear ask. The result returns through the daemon → MCP → wherever
  you are.
• Sessions are real but a snapshot. Logins set up at clone-time
  may have expired; if a page redirects to a login screen, fall back
  to "please sign in here once" rather than trying to fill credentials.
• Treat screenshots like screenshares. They can reveal unrelated
  open tabs, account names, notifications. Show only what the user
  asked for and crop when you can.