The Wazzi Browser Scripts Connector

Author and test Agent Center browser scripts by conversation — the AI drives a real Chrome on your agent-backend worker VM using the same recorder that agents use in production. First-party, org-scoped, and requires no credentials.

August 27, 2026
8 min read

Path: Connectors → Wazzi Browser Scripts → Configuration

What this connector does

Wazzi Browser Scripts is a first-party MCP connector that lets an AI assistant build and test Agent Center browser scripts by conversation. The model drives a real Chrome running on your organization's agent-backend worker VM — the same browser pool, the same login profiles, and the same replay engine that agents use in production. Every action it performs is captured as a script step using the recorder's own selector logic, so a chat-authored script is indistinguishable from a hand-recorded one and replays through identical code.

Why the VM and not the caller's machine: the value of these scripts is that they run unattended inside a login profile with 2FA already satisfied. A script authored against your own browser would be tied to your session, your cookies, and possibly a different tenant — and would break the moment an agent tried to replay it against the profile's session. Authoring the script in the environment it will actually run in is what makes the result trustworthy.

Because Wazzi Browser Scripts is first-party, there's nothing to configure and no external credentials to enter. Every request is org-scoped server-side, sessions are pinned to your organization's agent-backend Chrome pool, and every persisted script is owned by your org.

The connector exposes 36 tools across authoring, replay, and script management. Grouped by phase:

  • Session control (4 tools) — session_start, session_login (open the target login profile), session_status, session_end.
  • Page inspection (4 tools) — page_read, page_text, inspect_element, screenshot.
  • Page interaction (7 tools) — page_navigate, click, click_at, fill, select_option, press_key, batch (multi-action sequence in one call).
  • Data extraction & checks (2 tools) — extract, add_check.
  • Draft management (5 tools) — step_options, draft_get, draft_drop_step, draft_refine, draft_save.
  • Replay & debug (7 tools) — replay_start, replay_run, replay_status, replay_interrupt, replay_jump, replay_patch_step, replay_end.
  • Script library (4 tools) — list_scripts, get_script, update_script, delete_script.
  • Login profiles (3 tools) — list_logins, create_login, update_login.

Before you start

For this connector to have a Chrome to drive, your organization must have Agent Center enabled and at least one login profile configured (the browser profile a script authenticates against — where 2FA lives). Login profiles can be created inside this connector via create_login, or in the Agent Center UI.

Beyond that, there's no per-user setup — just enable the connector on the user's group in Wazzi.

What this connector unlocks for your team

Once configured, members with the right MCP permissions can ask Claude / ChatGPT / Cursor things like:

  • "Start a session in the Streamline login profile, log in, and record a script that pulls the guest-arrivals report for tomorrow."
  • "Show me every button on this page so I can pick the right one to click."
  • "Fill the search box with '405 W Ocean Blvd' and press Enter — save that as a step in the current draft."
  • "Extract the reservation IDs from the results table into a variable called reservations."
  • "Add a check that the confirmation banner shows 'Guest checked in' before moving on."
  • "Take a screenshot right now so I can eyeball what state the page is in."
  • "Save the current draft as a script called Streamline · Arrivals Export and end the session."
  • "Replay the Streamline · Arrivals Export script and stop if any step fails."
  • "Replay jumped to a failing step — patch it: replace the CSS selector with the aria-label version and continue."
  • "List every script tagged 'streamline' and show me which ones were last modified this month."

The exact set of available actions depends on which MCP toggles are flipped on for the user's group in Wazzi — see Managing Permissions. Write tools (session control, script save/delete, login management) can be restricted independently from reads.

The authoring loop, at a glance

  1. Start a session in a login profile (session_start + session_login). The Chrome opens on the agent-backend VM, authenticated as that profile.
  2. Interact with the page — page_navigate, click, fill, etc. Each action becomes a step in a live draft using the recorder's selector logic.
  3. Inspect + verify — page_read, screenshot, inspect_element, add_check. Confirms the model actually clicked what it thinks it clicked before committing.
  4. Refine the draft — draft_get, draft_drop_step, draft_refine. Prune dead steps, adjust selectors, tweak assertions.
  5. Save + replay — draft_save promotes the draft into a persisted script. Then replay_start / replay_run exercises it end-to-end, and replay_patch_step lets the model fix any failing step in place before saving again.

Steps — enabling Wazzi Browser Scripts in Wazzi

1. From the Connectors catalog, click Configure on the Wazzi Browser Scripts tile.

You'll land on Wazzi Browser Scripts' Configuration tab:

Wazzi Browser Scripts connector Configuration tab

2. Read the notice — there are no credentials to enter.

The configuration tab shows an information notice reminding you that Agent Center must be enabled and at least one login profile configured for the tools to have a browser to drive.

3. Click Test Connection.

Wazzi confirms the agent-backend browser pool is reachable and reports how many login profiles are available for your org.

4. Click Save Configuration.

Wazzi Browser Scripts moves to the Active section of the catalog.

Troubleshooting

  • session_start fails with "no login profile". Your org hasn't created a login profile yet. Create one with create_login (name + start URL) or in the Agent Center UI, then complete the profile's login by running session_login once and satisfying 2FA — after that the profile is reusable.
  • session_start fails with "all workers busy". The agent-backend browser pool is at capacity. Wait a minute and retry, or increase pool size if your org has hit its ceiling.
  • Click / fill returns "element not found". The page hasn't finished rendering, or the selector the model chose doesn't match anything. Run page_read or inspect_element first to enumerate what's actually on the page. For SPAs, a short wait after navigation is often enough.
  • replay_start on a saved script fails at step N. Selectors drift when a site's markup changes. Use replay_jump to land at step N, then replay_patch_step to update the selector without leaving the replay session. draft_save at the end promotes the fixed version.
  • Session left running. Sessions time out on their own, but always call session_end when you're done — it frees the browser worker for the next caller.
  • Login profile drifted (cookies expired / 2FA lapsed). Run session_login against the profile once to re-satisfy the login flow. The profile persists the fresh cookies for the next unattended run.

Best practices

  • Always work in the profile the script will run in. Authoring against your own browser is faster but ships scripts that only work in your session. Use session_start with the target login profile from the beginning.
  • Add checks liberally. add_check steps assert the page reached the expected state before the script keeps going. A script without checks silently marches forward when a page 500s; a script with checks fails loudly on the exact step that broke.
  • Prefer extract over screenshots for data. A saved extract step pulls structured data (text, table rows, attributes) that downstream steps can reference. Screenshots are for one-off visual verification while authoring.
  • Use batch for tight sequences. batch runs multiple actions in a single tool call — cuts context/latency for common patterns like "click, wait, fill, submit". Each sub-action still becomes its own script step.
  • Restrict destructive tools. delete_script, update_login, and session mutations can affect other agents/scripts. Only grant those permissions to authoring / ops groups — see Managing Permissions.
  • Name scripts and login profiles clearly. Scripts get invoked by name from agent actions — Streamline · Arrivals Export is easier to reason about than arrivals_v2_final_FINAL.

Frequently asked questions

Do I need to configure anything?
No. This is a first-party connector with no external credentials. Just enable it on the user's group in Wazzi.

Can users from another organization drive my browser or read my scripts?
No. Every tool call filters by organization_id — sessions, login profiles, and saved scripts are all org-scoped. Cross-org access is impossible.

Whose browser is the AI actually driving?
Not yours. The Chrome runs on your organization's agent-backend worker VM, inside the login profile you named on session_start. That's on purpose: it's the same environment agents use in production, so what you author is exactly what will replay.

What's a login profile?
A persisted browser profile — cookies, localStorage, extensions — tied to one login flow. You create it once, satisfy 2FA once, and every subsequent session that names the profile picks up the authenticated state. Login profiles are what make unattended agent runs possible.

Does this replace the manual recorder in Agent Center?
Not entirely. The recorder is faster for the "walk through a UI and capture what I do" case. This connector is for when the model itself is exploring — deciding which button to click based on what's on the page — and for iterating on an existing script by refining specific steps.

Can I preview a screenshot mid-conversation?
Yes — screenshot returns the current viewport as a base64 image, which most MCP clients render inline. Handy for confirming the page reached the state you expected before committing the next step.

What happens if I disable Agent Center after wiring up this connector?
The connector stays enabled but every session-based tool fails with a "no browser workers available" error — because there's no pool for it to draw from. Re-enable Agent Center to restore full function.

What's next

Was this article helpful?