Give an AI agent eyes on a live website or app. The agent browses it, interacts with it, and tells you whether a given task or check passed. Works on localhost or any URL. Use for visual QA, flow validation, regression checks, or anything that needs a real browser to verify.

LOCALHOST SUPPORT: Pass any localhost URL (e.g. http://localhost:3000) and it Just Works. A secure tunnel is automatically created so the remote browser can reach your local dev server — no manual ngrok setup, no port forwarding, no config.

SCOPE PER CALL: Keep each call to ONE focused check — a single page or a short interaction on a single screen (login, submit a form, verify a heading). For anything spanning multiple pages or long multi-step flows, split into SEPARATE calls — the remote browser agent has a ~25-step internal budget per call, and long single calls risk client-side timeouts. Example: instead of "log in, then go to settings, then update profile, then verify," make three calls: (1) log in & verify dashboard, (2) update settings, (3) verify profile change.

CREDENTIALS: pass them as PARAMETERS, not only in the description. Naming an account in description alone does not make the agent use it — it falls back to the environment's stored credential. Use username/password (or credentialId) for the run's identity, auth.username/auth.password to pin the precondition login, and loginCredentials for accounts the agent must use at a login form it hits PART-WAY through the task (e.g. set a password → bounced to sign-in → log in as the account you just created). Anything you specify beats the environment's default for every login in the run; the result reports the identity actually used under logins.

Probe one or more URLs and return their rendered state — screenshot, page metadata (title/finalUrl/statusCode/loadTimeMs), structured console errors, and per-URL network summary (refetch loops collapse into one row by origin+pathname).

WHEN TO USE: "did I just break /settings?" / "smoke-test these 5 routes after my refactor" / "what's actually rendering at /dashboard?" — fast (<10s for 1 URL, <25s for 20), no LLM cost, no agent loop.

NOT FOR: scenario verification (sign in → click X → assert Y), interaction (clicks, form fills, scrolls), or anything requiring agent decisions. Use check_app_in_browser for those.

LOCALHOST SUPPORT: any localhost URL is auto-tunneled. Pre-flight TCP probe fails fast (<2s) if the dev server isn't listening.

BATCH MODE: pass up to 20 targets in one call to share browser session + tunnel — dramatically faster than firing parallel single-URL probes (one execution unit, not N). Per-URL waitForSelector / waitForLoadState / timeoutMs override defaults.

READINESS: navigation settles on CONTENT (the page's DOM going quiet), bounded — not on network silence, which never arrives on a live app, and not on 'load', which blocks on third-party embeds. The default is right for SPAs; reach for waitForSelector, not waitForLoadState, when you need to wait for something specific.

A single failed target's error appears in result.error without failing the whole batch — the other results stay valid.

Trigger a browser-agent crawl of a web app to build the project's knowledge graph. The crawl systematically explores pages, UI states, and navigation flows, then populates the backend's knowledge graph so future evaluations and tests have context about the app.

LOCALHOST SUPPORT: Pass any localhost URL (e.g. http://localhost:3000) and it Just Works. A secure tunnel is automatically created so the remote browser can reach your local dev server.

WHEN TO USE: after a significant new feature, a new environment, or when onboarding a project. NOT for per-change verification — use check_app_in_browser for that.

SCOPE: one crawl per call against one URL. The crawl is long-running (minutes to tens of minutes depending on app size) and populates backend state asynchronously; the tool returns the execution status once the workflow completes. This does NOT return pass/fail — it returns executionId + status + outcome.

Manage DebuggAI projects. Pass an "action":

• "get" {uuid} → one project with full detail.

• "list" {q?, page?, pageSize?} → paginated project summaries.

• "create" {name, platform, (teamUuid|teamName), (repoUuid|repoName)} → create a project. The repo must be GitHub-linked; names resolve by case-insensitive exact match.

Note: there is no update/delete here — rename/delete a project from the DebuggAI web app.

Manage environments (and their login credentials) under a project. Pass an "action":

• "get" {uuid, projectUuid?} → one environment with credentials inline (passwords never returned).

• "list" {projectUuid?, q?, page?, pageSize?} → paginated environments. projectUuid auto-resolves from the git repo if omitted.

• "create" {name, url, description?, projectUuid?, credentials?} → create an env, optionally seeding credentials.

• "update" {uuid, name?, url?, description?, addCredentials?, updateCredentials?, removeCredentialIds?} → patch env + manage credentials.

• "delete" {uuid, projectUuid?, confirm?} → delete env (DESTRUCTIVE; requires confirmation).

• "sessions" {uuid, username?, credentialId?} → captured login sessions this env is holding, and whether each would be reused.

• "clearSessions" {uuid, username?, credentialId?, confirm?} → invalidate them so the next run logs in for real.

SESSIONS: runs reuse a warm authenticated session per account instead of logging in every time. That is why a check can report "no login form" — it was already signed in. Use "sessions" to see whose session is held, "clearSessions" to drop it, or pass freshSession:true on a single check_app_in_browser call to bypass reuse without clearing anything.

Manage and run test suites. Identify a suite by suiteUuid, or suiteName + a project identifier (projectUuid|projectName). Pass an "action":

• "list" {projectUuid|projectName, search?, page?, pageSize?} → paginated suites with status/pass-rate.

• "create" {name, description, projectUuid|projectName} → create a suite.

• "run" {suiteUuid|(suiteName+project), targetUrl?} → run all tests async. Poll with action:"results".

• "results" {suiteUuid|(suiteName+project)} → suite + per-test outcomes.

• "delete" {suiteUuid|(suiteName+project), confirm?} → soft-delete (DESTRUCTIVE; requires confirmation).

Manage individual test cases within a suite. Pass an "action":

• "create" {name, description, agentTaskDescription, suiteUuid|(suiteName+project), relativeUrl?, maxSteps?} → add a test case (NOT auto-run).

• "update" {testUuid, name?, description?, agentTaskDescription?} → patch a test case.

• "delete" {testUuid, confirm?} → soft-delete (DESTRUCTIVE; requires confirmation).

Look up workflow executions (history of check_app_in_browser, trigger_crawl, and test-suite runs). Pass an "action":

• "get" {uuid} → one execution with FULL detail (nodeExecutions, state, errorInfo) + any screenshot/gif artifacts.

• "list" {projectUuid?, status?, page?, pageSize?} → paginated execution summaries. status ∈ completed|running|failed|cancelled|pending.

Tip: after a fresh check_app_in_browser run, poll action:"get" with the returned executionId until artifact URLs are available.