AI browser automation testing is not one tool. It is eighteen, and you can read every line.

The tool list is a single Anthropic.Tool[] array at /Users/matthewdi/assrt-mcp/src/core/agent.ts, lines 16 to 196. Eighteen tools: navigate, snapshot, click, type_text, select_option, scroll, press_key, wait, screenshot, evaluate, create_temp_email, wait_for_verification_code, check_email_inbox, assert, complete_scenario, suggest_improvement, http_request, wait_for_stable. Ten of those are the mouse-and-keyboard tools you would expect. The other eight are where AI browser automation testing gets interesting: an inbox, OTP polling, arbitrary HTTP, DOM-stability via MutationObserver injection, mid-test bug filing, and the assert/complete bookkeeping. Everything the agent is capable of is enumerable by grepping the word name in one file.

Because most real bugs are not in the DOM. Clicking 'Connect Telegram' in your app might show a green checkmark and still fail to actually deliver a message to the Telegram Bot API. A mouse-and-keyboard-only agent has no way to tell the difference between a correct backend and a lying UI. http_request, defined at agent.ts:925-955, lets the agent GET https://api.telegram.org/bot{token}/getUpdates right after the UI action and assert on the payload. The response body is fed back into the agent context so the next step (the assertion) sees it. This single primitive closes the 'works in staging, breaks in production' loop for any integration where the truth lives in a third-party API: Telegram, Slack, GitHub, Stripe webhooks, your own backend.

A fixed test@myapp.com means every run of your signup scenario hits the same user record, which means deduplication code paths, email-already-exists errors, and rate limits ruin your test within a week. Assrt's create_temp_email, defined at agent.ts:850 and implemented at /Users/matthewdi/assrt-mcp/src/core/email.ts, calls https://api.internal.temp-mail.io/api/v3/email/new per run and gets a brand-new address plus a token. The next tool, wait_for_verification_code (agent.ts:858), polls that specific inbox every 3 seconds for up to 60. A regex inside DisposableEmail.waitForVerificationCode extracts 4-to-8-digit codes and common 'code: 123456' variants. No Zapier, no mail mock, no test-user cleanup cron. The inbox is born, used once, and forgotten.

Yes, at agent.ts:956-1009. When the agent calls wait_for_stable, Assrt runs this.browser.evaluate with a literal JavaScript string that creates a MutationObserver on document.body with childList, subtree, and characterData set to true. Every mutation increments window.__assrt_mutations. The agent then polls that global every 500ms. If the counter stops changing for the configured stable_seconds (default 2), the wait unblocks. When the scenario ends, the observer is disconnected and the globals are deleted. The whole thing is about fifty lines, and the reason it matters is that AI browser automation testing against modern SPAs has to deal with streaming tokens, optimistic UI, and React re-renders; fixed sleeps either cut off the assistant mid-response or waste eight seconds on a page that finished loading in one. A DOM-stability primitive adapts.

suggest_improvement (agent.ts:914-924) takes title, severity (critical, major, minor), description, and suggestion. When the agent calls it, Assrt emits an improvement_suggestion event over the SSE stream and logs it on the scenario report. In MCP mode, the event shows up inline in Claude Code's output next to the test run. In CLI mode with --json, it lands in the JSON report. It is not a Linear ticket or a GitHub issue out of the box; it is a structured record that the agent noticed something that was not strictly part of the scenario. Teams wire it into whatever bug tracker they already use. The important part is that happy-path verification and UX bug filing come out of the same run; most AI browser automation testing tools treat those as two separate workflows.

Drift in AI browser automation testing usually means one of three things: the locator broke because a class name changed, the model hallucinated an element that does not exist, or a fixed sleep did not match the real page timing. Assrt sidesteps all three. Scenarios are written as intent ('Click the Sign up button', not 'click .btn-primary:nth-child(2)'). Before each action, the agent calls snapshot (agent.ts:779) and gets a fresh accessibility tree with ref IDs; a ref that worked two steps ago but is now stale triggers a fallback to text matching. And wait_for_stable adapts to real page timing, so scenarios do not break on a slow CI box. When something does drift, the same agent surfaces it through suggest_improvement and assrt_diagnose (the MCP tool that re-opens the failing URL and proposes a corrected scenario). You get a specific diff, not a generic 'the test flaked.'

Those are browser agents built for general web tasks: booking flights, filling forms, scraping. They are excellent at that. Assrt is a browser agent narrowed to QA testing, which means it ships primitives general agents do not: the assert tool that splits passed scenarios from failed ones, complete_scenario that terminates a test run cleanly, suggest_improvement that files bugs on purpose, the #Case markdown format that a whole team can share via git, scenario continuity across multiple cases in one browser, and a video+screenshot recorder attached to every run. A general browser agent can certainly type into a signup form, but it will not emit a pass/fail verdict, will not poll an inbox on your behalf, will not file a bug report, and will not give you a scenario.md file you can check into your repo. If you want an agent to do end-to-end QA against your own web app, the primitives matter more than the model.

Yes. Extension mode (--extension flag, or extension: true in the MCP call) connects Assrt to your running Chrome via @playwright/mcp's --extension transport. All your cookies, localStorage, and 2FA state are already there. First run, the agent prints a token that you paste back; the token saves to ~/.assrt/extension-token and future runs are zero-setup. This is the single most useful switch for testing behind auth: the agent uses your real session, so flows like 'invite a teammate to my workspace' work without provisioning a test account, and flows like 'verify the Stripe webhook fired' can hit your production-mode backend with your real API keys.

The agent, the MCP server, and the CLI are open source. /Users/matthewdi/assrt-mcp is the MCP server and test runner. /Users/matthewdi/assrt is the web app. The 18-tool agent loop, the wait_for_stable MutationObserver injection, the disposable email client, the HTTP request tool, and the suggest_improvement primitive are all plain TypeScript you can clone, read, and modify. There is an optional cloud service at app.assrt.ai that stores scenario runs and artifacts for sharing, but the test engine does not depend on it; you can run the whole stack against localhost forever without ever touching assrt.ai. Compare that to closed-source AI browser automation testing SaaS that charges $7,500 a month and locks your generated tests inside their dashboard.

Under the hood, Assrt uses @playwright/mcp as its browser control layer (agent.ts:3 imports McpBrowserManager, which spawns the Playwright MCP server over stdio). Every click, type, and scroll your AI browser automation test performs is a real Playwright call. The scenario format above those calls is markdown (#Case blocks), not YAML or a proprietary DSL. If you ever need to drop into handwritten Playwright, the scenario's intent translates cleanly: a step like 'Click the Sign up button' becomes page.getByRole('button', { name: 'Sign up' }).click(). Closed-SaaS tools that emit proprietary YAML force you to re-author tests if you ever move off the platform; the Assrt format is readable at the top of this page. No migration cost either way.