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
- Start a session in a login profile (
session_start+session_login). The Chrome opens on the agent-backend VM, authenticated as that profile. - Interact with the page —
page_navigate,click,fill, etc. Each action becomes a step in a live draft using the recorder's selector logic. - Inspect + verify —
page_read,screenshot,inspect_element,add_check. Confirms the model actually clicked what it thinks it clicked before committing. - Refine the draft —
draft_get,draft_drop_step,draft_refine. Prune dead steps, adjust selectors, tweak assertions. - Save + replay —
draft_savepromotes the draft into a persisted script. Thenreplay_start/replay_runexercises it end-to-end, andreplay_patch_steplets 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:
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_startfails with "no login profile". Your org hasn't created a login profile yet. Create one withcreate_login(name + start URL) or in the Agent Center UI, then complete the profile's login by runningsession_loginonce and satisfying 2FA — after that the profile is reusable.session_startfails 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_readorinspect_elementfirst to enumerate what's actually on the page. For SPAs, a short wait after navigation is often enough. replay_starton a saved script fails at step N. Selectors drift when a site's markup changes. Usereplay_jumpto land at step N, thenreplay_patch_stepto update the selector without leaving the replay session.draft_saveat the end promotes the fixed version.- Session left running. Sessions time out on their own, but always call
session_endwhen you're done — it frees the browser worker for the next caller. - Login profile drifted (cookies expired / 2FA lapsed). Run
session_loginagainst 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_startwith the target login profile from the beginning. - Add checks liberally.
add_checksteps 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
extractover screenshots for data. A savedextractstep pulls structured data (text, table rows, attributes) that downstream steps can reference. Screenshots are for one-off visual verification while authoring. - Use
batchfor tight sequences.batchruns 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
- Set up your first login profile — see the Agent Center documentation on browser profiles.
- Restrict who in your org can invoke Wazzi Browser Scripts actions: Managing Permissions.
- Wire Wazzi Browser Scripts into your AI tool: Connecting Claude or Connecting ChatGPT.