Agent Browser Automation: Only After MCP Fails? Branch Criteria
When choosing agent browser vs MCP, the default is connectors (MCP) first. If a structured tool exists, it is usually more reproducible and easier to permission than a DOM click/screenshot loop. Use the browser only after MCP is missing or failed, or when the goal is visual/UI verification. Cursor’s Browser is also exposed as MCP tools under the hood; in this post “browser” means the navigate · click · type · screenshot UI-automation axis.
Three topics: why MCP first, signals to fall back to the browser, and login/2FA handoff. No pricing, plan, or token numbers. No auth bypass and no invented UI click-paths.
Why use MCP first?
One-line answer: MCP connectors attach to external systems through named, schema’d tools. Permissions, auditability, and failure isolation are clearer than UI automation, and you avoid burning context on DOM snapshots and screenshots.
Per Cursor’s docs, MCP exposes Tools, Resources, Prompts, and related capabilities. You enable servers in Customize or mcp.json. Tools under Available Tools are used when relevant; they follow the same approval / Run Modes as other agent actions (e.g. allowlisted tools in Auto-review). If a server crashes or times out, that call fails while other MCP servers keep working.
| Axis | MCP (connector) | Browser UI automation |
|---|---|---|
| I/O | Named args, structured replies | DOM/screenshots, console, network logs |
| AuthZ | OAuth, scopes, enterprise allowlists | Tabs, cookies, origin allowlists (enterprise) |
| Repro | Same tool name + args | Sensitive to layout, copy, A/B |
| Failure | Isolated per server/tool | One bad click can tangle the session |
| Best for | Issues, Drive files, Slack search, API-shaped work | Local UI checks, a11y, visual regression |
When connector-first is right
- An official or team MCP already exists — Jira, Confluence, Drive, Slack, and similar read/write tools.
- You need audit and least privilege — scopes and tool allowlists make “what was called” obvious.
- The result is data — issue bodies, file metadata, search hits—not pixels.
Putting the browser first often reinvents the same Slack/Drive work as login screens, menu hunting, and guessed selectors. If a connector exists, fix the connector first (connection, auth, scopes, membership).
Sample rule line:
Prefer configured MCP/connectors for external systems (issue trackers, Drive, Slack, etc.).
Use browser UI automation only after MCP is missing, unauthorized, or failed — or when the goal is visual/UI verification.
Never invent click-paths to bypass login or 2FA; hand those to a human.What signals mean “fall back to the browser”?
One-line answer: Fall back when a connector is absent or its calls failed, and the goal can only be confirmed via screen, console, or network. “MCP feels slow” is not enough—check logs, auth, and tool names first.
Cursor Browser needs no extra install: the agent can open pages, click, type, scroll, screenshot, read console, and (in the Agent panel) inspect network traffic. Subagent docs also treat Browser as a separate path because DOM and screenshots are noisy. Powerful, but expensive on context.
| Signal | Browser fallback? | Do this first |
|---|---|---|
| No MCP for that service in the tool list | Yes (if UI is required) | Check Customize / mcp.json for a connector |
| MCP tool fail, timeout, needsAuth | Conditional | Output → MCP Logs; re-auth; toggle server |
| Local dev-server UI verification | Yes | Reuse the running port (dev-server awareness in docs) |
| A11y / visual / console-error checks | Yes | @browser for contrast, ARIA, keyboard, console |
| API/connector read is enough | No | Stay on connector tools |
| Browser tools missing over SSH/remote | Environment issue | Local workspace, team policy, documented limits—do not invent bypass click-paths |
Practical fallback order
- State the goal in one line — “read issue body” vs “screenshot post-login dashboard.”
- Search Available Tools for a connector — if present, try MCP only.
- Classify failures — missing install / auth / scopes·membership / crash. Fix the connector; do not UI-bypass.
- If still blocked or UI is the goal — switch to Browser (or a team-allowed browser MCP). Keep approval on (docs default: browser tools need approval).
- Record the path — note “browser fallback” in progress/rules so the next session does not rediscover the connector.
For enterprises, browser features and origin allowlists sit under MCP Configuration. Automatic browser_navigate is limited to allowlisted origins; on a non-allowlisted origin the user opened manually, click/type may be blocked. Put that policy boundary into the fallback design.
How should login / 2FA be handled?
One-line answer: Login and 2FA are human handoff only. Do not invent password/OTP entry paths for the agent. After a human finishes auth, continue only on an already authenticated session.
Cursor Browser may persist cookies and storage per workspace across sessions. Help text may say to tell the agent how to sign in for gated pages, but the practical rule is: never put credentials or 2FA codes in chat/rules; the human completes SSO/password/OTP in the browser. This post does not cover bypasses, captcha solving, or automated OTP entry.
| Step | Human | Agent |
|---|---|---|
| 1. Detect auth wall | — | Report “login/2FA screen; stopping” only |
| 2. Login / 2FA | Complete on their device / SSO / OTP | No password, OTP, or recovery-code requests or storage |
| 3. Confirm session | Confirm the target page is visible | Resume read/click under approval after auth |
| 4. If stuck | Check policy, origin, session expiry | No new bypass paths; leave a Blocked note |
Copy-paste rule for the agent
If a login, SSO, captcha, or 2FA challenge appears:
1) Stop automated credential entry.
2) Tell the user what screen you see (no secrets).
3) Wait for the human to finish auth in the browser.
4) Resume only on the post-auth page the user confirms.
Never invent UI paths to bypass auth. Never paste passwords, OTP, or recovery codes into chat, rules, or files.Session persistence does not mean secrets are safe on shared machines or in screenshots. Keep manual approval for sensitive accounts; humans decide logout and session cleanup when the task ends.
What should you remember?
Treat agent browser as a fallback after MCP failure (or when UI verification is the goal). Connectors win on structure, permissions, and isolation; the browser wins on screen, console, and network checks. Login/2FA stay with the human; the agent continues only after auth, under approved actions. Pricing, invented click-paths, and auth bypass are out of scope.
Related habits
- Check MCP on/off and Available Tools in Customize before opening the browser.
- Keep browser tool approval and allow/block lists; docs warn against auto-run on untrusted sites.
- In progress notes, leave one line: path was MCP, browser, or human-auth.