Browser Gui Inspect

Browser GUI Inspect Skill

Purpose

Many controllers and web-based tools NetClaw talks to via REST API also have GUI-only reports, dialogs, or visualizations the API doesn't expose — and some tools (classic SDN controller consoles, vendor support portals, SaaS admin consoles) have no NetClaw API integration at all. This skill is the controller-agnostic fallback: it drives a real, persistent, manually-authenticated Chrome session to read, search, confirm, and capture whatever an operator needs from a web GUI.

This skill deliberately contains no per-vendor DOM/selector knowledge. Every invocation is directed by the operator's own target URL and intent at request time — nothing about any specific controller's page layout is hardcoded here (Constitution VI — Multi-Vendor Neutrality). See specs/048-chrome-devtools-browser-inspection/ for the full spec, research, and design behind this skill.

Golden Rule — Read/Confirm/Search Only, Never a Config-Change Mechanism

This skill's interactive tools (click, fill, fill_form, drag, press_key, type_text, handle_dialog, upload_file) are for reading, filtering, searching, and confirming state on a page — never for submitting, applying, or committing a configuration change to network infrastructure. If a request would require clicking something like "Commit," "Apply," "Submit," "Deploy," or "Save" on a controller's configuration workflow, stop and tell the operator that this must go through the relevant API-based skill instead (e.g., the ACI, Panorama, or FortiManager skill), which implements the proper observe→baseline→modify→verify workflow and ServiceNow CR gating (Constitution I, II, III, VIII). Using this skill to bypass that workflow would create an unaudited, unverified side door around NetClaw's safety model — see specs/048-chrome-devtools-browser-inspection/research.md R8 for the full rationale.

MCP Servers — Headless and Watch Mode

This skill uses tools provided by the chrome-devtools-mcp package (official Chrome DevTools team, chrome-devtools-mcp on npm), registered twice:

Both are the same package, spawned locally over stdio via npx -y chrome-devtools-mcp@latest. See mcp-servers/chrome-devtools-mcp/README.md. Every workflow below (gap-fill, API discovery, general automation) works identically against either server — pick the server based on whether the operator asked to watch, then use that server's tools for the whole request.

Recognizing a Watch Mode request: if the operator's phrasing signals they want to observe the browser (e.g., "watch", "show me", "let me see it", "I want to see this happen"), use chrome-devtools-mcp-visible's tools for the entire request. Otherwise default to the headless chrome-devtools-mcp server. This is a per-request choice, not a global setting — the same skill, same workflows, just a different server backing the tool calls.

Configuration

No environment variables — chrome-devtools-mcp takes all configuration as CLI flags, not env vars. NetClaw's registration pins --headless=true for automated use; everything else (including the persistent profile holding sign-in sessions) uses the tool's own default at ~/.cache/chrome-devtools-mcp/chrome-profile.

No credential-bearing environment variable exists for this skill. NetClaw never requests, stores, or transmits credentials for any target site (FR-005) — see the Headless/Headed Mode & Sign-In section below.

Workflow 1: Fill a Gap in an Existing Controller Skill (P2)

Use this when a controller's REST API doesn't expose a report, setting, or visualization the operator needs, but its web dashboard shows it.

Input:

• target (required) — the vendor dashboard/GUI page URL
• intent (required) — plain-language description of what to read or extract (e.g., "get the bridge domain list from this ACI tenant page")
• actions (optional) — a sequence of navigate/click/fill/read steps if multi-step interaction is needed
• capture (optional, default ["screenshot", "console"]) — artifact kinds to capture

Step 1: Navigate using the persistent profile

Tool: navigate_page
Args: { "url": <target> }

Step 2: Detect a sign-in wall before proceeding

Read the page (via take_snapshot or take_screenshot) and check whether it looks like a login/SSO page rather than the expected dashboard content. If so, stop and return:

status: "sign_in_required"

Do not proceed to interact with a login form, and do not return an empty or fabricated result — report this distinctly so the operator knows a manual sign-in (see below) is needed, per FR-008.

Step 3: Perform the requested read/confirm/search actions

Using click, fill, hover, press_key, etc. as needed to reach the information described in intent — e.g., selecting a tenant, expanding a section, applying a filter. Reiterate: these actions are for navigating to the information, never for submitting a change.

Step 4: Capture the requested artifacts

• take_screenshot for a visual capture
• take_snapshot or targeted reading of page text/structure for the extracted value
• list_console_messages if "console" is requested

Step 5: Return the result

{
  "result": "<the extracted value(s)/text answering intent>",
  "artifacts": { "screenshot_path": "...", "console_log": [...] },
  "status": "ok" | "sign_in_required" | "blocked" | "timed_out"
}

Worked Example: ACI APIC Bridge Domains

"Pull the bridge domain list from the ACI tenant page in APIC — the API doesn't expose it the way I need."

1. navigate_page to the tenant's Bridge Domains page in APIC.
2. Confirm the session is authenticated (not a login page) — if not, return sign_in_required.
3. Read the bridge domain table via take_snapshot (accessibility-tree text read is more reliable than parsing a screenshot).
4. Return the bridge domain names/subnets found, plus a screenshot for visual confirmation.

Workflow 2: Discover an Undocumented Vendor API (P3)

Use this when building a new API-based skill for a controller whose public API documentation is incomplete — load the dashboard feature in question and observe what network calls it actually makes.

Input:

• target (required) — the dashboard page to load
• intent (required) — the action to trigger (e.g., "click Refresh on the client list filtered by SSID")
• capture: ["network_requests"] (required for this workflow)

Step 1: Navigate and authenticate

Same as Workflow 1, Steps 1-2 — navigate to target, confirm the session isn't sign-in-walled.

Step 2: Trigger the action under investigation

Perform the click/fill/navigation described in intent that causes the dashboard to make the network call(s) of interest.

Step 3: Enumerate observed network activity

Tool: list_network_requests

This returns every request (method, URL, status) made since the page loaded — including calls the dashboard makes that aren't part of any published API documentation.

Step 4: Retrieve full detail on a specific request

Tool: get_network_request
Args: { "requestId": <id from the list above> }

Returns the full method, URL, status, and request/response body for that call — everything needed to replicate it in a future API-based skill.

Step 5: Summarize the finding

Report the discovered endpoint (method + URL pattern), the request payload shape, and the response shape, so a contributor can go implement it as a proper API-based skill rather than continuing to rely on GUI automation for that use case going forward.

Worked Example: Meraki Dashboard Client List

"Load the Meraki dashboard's client list page and tell me what API calls it makes when I filter by SSID."

1. navigate_page to the network's Clients page in the Meraki dashboard.
2. Apply the SSID filter (a click/fill interaction — reading/filtering, not a config change).
3. list_network_requests to see what the filter action triggered.
4. get_network_request on the relevant XHR/fetch call to get its exact URL, query parameters, and response shape.
5. Report back the endpoint found, so it can inform a future Meraki API-based skill enhancement.

Workflow 3: General-Purpose Web GUI Automation (P4)

Use this as the broadest fallback: an ad hoc navigate/read/interact request against a browser-based tool with no existing NetClaw integration — a classic SDN controller GUI (e.g., OpenDaylight or ONOS), a vendor support/TAC portal, or a SaaS admin console with incomplete API coverage.

Input:

• target (required) — the page to load
• intent (required) — free-form description of what to read or do; no page-structure assumptions are made ahead of time