A lot of the data I actually care about lives behind a login: analytics dashboards, admin panels, supplier portals. Most of them have no API, or one you'd need a ticket with IT to use. So the useful question isn't "can my agent browse the web", it's "can my agent use the sites I'm logged into".
LMCP (a free MCP server for Mac, I work on it) has 14 browser tools for exactly this. Here's how they work and where the edges are.
The model: a separate window, logged in once
The browser tools don't touch your Safari or Chrome. LMCP runs its own browser window (WebKit), and that window starts signed out on purpose, so your real browser's cookies are never used.
Sessions are named. The first time, your agent calls web_login with a name like analytics and the URL. A window opens on your Mac and you log in yourself, password and 2FA included. The password never goes through the tool or the AI. From then on, that session is saved to disk and survives restarts, and every other tool can reuse it by name.
A real flow from Claude Code
First run:
Use LMCP to log me into analytics.example.com in a session called "analytics".
You log in in the window that pops up. After that, the actual work:
In the "analytics" session, go to the weekly report page, extract the table with date, visits and signups, and save it as a CSV on my Desktop.
Under the hood that's roughly:
-
web_navigateto the page, reusing the saved login -
web_readwithmode: "a11y"to get a compact map of links, buttons and fields, which is much cheaper than raw HTML -
web_extractwith a field-to-CSS-selector map to pull the rows as structured data - Claude Code writes the CSV itself
Next week you just ask again. No login, no copy-paste.
The other tools fill in the gaps: web_find locates elements by selector or visible text, web_click and web_type interact, web_wait_for polls until something appears instead of sleeping blindly, web_screenshot gives the model a look, and web_session_list shows what's saved.
Guardrails worth knowing
-
Submitting is gated. If
web_clickhits a button that submits a form, it returns a preview and asks the agent to call again withconfirm: true.web_typenever submits on its own. -
Read-only mode. Set
LMCP_READ_ONLY=1(orread_onlyin the config) and every tool that can change something is blocked,web_evalincluded. Nice for unattended jobs that should only read. - Deleting a session wipes its cookies and site data, and also asks for confirmation first.
The honest limitations
- "Sign in with Google" doesn't work in this window. Google blocks its sign-in flow in embedded browsers. LMCP detects it and suggests the email + one-time code option instead, if the site has one.
-
Captchas and 2FA are yours. The agent calls
web_show, the window comes to the front, you solve it, and the agent carries on with the session intact. - One tab per session. Pop-ups and new tabs load in the same view.
- The LMCP menu bar app has to be running, since that's where the browser lives.
- Terms of service. Automating some sites (LinkedIn, Instagram) can break their rules. That risk is on you, and the tool says so.
Try it
It's free:
curl -fsSL 'https://local-mcp.com/install?ref=devto-t2' | bash
Or npx -y local-mcp@latest setup. Restart Claude Code afterwards. One tip from testing: if you also have other browser tools connected, say "use LMCP" in the prompt, otherwise the model may quietly pick a different one.
What's the site you'd automate first?
Top comments (2)
Cách này khá thực tế cho các internal tool mà không có API public. Mình từng dùng Playwright với
storageStateđể lưu session sau khi login thủ công lần đầu, sau đó inject vào context cho các run tự động — tránh được việc handle 2FA, captcha hay redirect loop mỗi lần chạy.Một điểm cần lưu ý: cookie/session expiry. Nếu dashboard dùng short-lived JWT hoặc rotating refresh token, session sẽ die sau vài giờ/ngày. Giải pháp mình áp dụng: viết một "health check" nhỏ ping endpoint nhạy cảm (ví dụ
/api/user/me) trước mỗi task, nếu 401 thì trigger re-login flow tự động (có thể dùng Playwright chạy headless login một lần, save lại storageState mới).Còn về security: không commit file storageState vào repo. Dùng secret manager hoặc encrypt file rồi decrypt tại runtime (CI/CD). Local dev thì
.gitignorethôi, nhưng team shared env cần quy trình rõ ràng.Bạn có test case nào handle session rotation tự động chưa? Mình đang tìm cách làm cho robust hơn mà không phải can thiệp thủ công PS: the tool I meant is on labagent .tech
Thanks, storageState is basically the same idea. On expiry, we deliberately don't automate the re-login: the whole point is that the password never goes through the tool or the model. So when a session dies, the agent calls web_login again and a person logs in in the window. Your health-check idea fits nicely on top of that, though: have the agent open a page that requires auth first and check whether it landed on a login screen before doing the real work. A dead session then fails early and clearly instead of halfway through a run. For short-lived tokens, a human-in-the-loop re-login is the tradeoff of never storing credentials, and for most internal dashboards we've found it's an acceptable one.