Browser Control

---
name: browser-control
description: Open, inspect, interact with, and verify websites or local web apps in Poracode's isolated browser. Use for visible page state, navigation, screenshots, console or network evidence, and end-to-end UI testing; do not use it for semantic service operations when a purpose-built connector is available.
---

# Browser Control

Use Poracode's `browser` MCP when the task depends on a rendered page, visible interaction, or local web app. If the request is really about structured data or a service operation and a purpose-built connector is available, use that connector instead. An explicit request for Poracode's browser wins.

## Workflow

1. Call `browser.api` when you need the current API map, then call `browser.enable` once before the first browser action.
2. Reuse a relevant tab from `browser.list_tabs`; otherwise open the exact URL the user supplied or the known local target. Do not guess a remote site or substitute web search when authentication blocks the requested page.
3. Establish the baseline with the current URL plus `browser.snapshot` or `browser.find`. Prefer accessible roles, names, and returned element refs over brittle selectors or coordinates.
4. Use `perform` for a bounded sequence of known actions: `{steps:[{action:"fill",ref:"@e1",text:"Ada"},{action:"click",ref:"@e2"},{action:"wait",text:"Saved"}]}`. It stops on failure and returns one final compact snapshot (`observe:"none"` omits it). Use `fill` for replacement and `type` for appending. Split batches at decisions, new targets, and navigation; do not replay completed steps after failure.
5. Include a condition `wait` at the end of a batch for asynchronous changes, then inspect its returned observation. After navigation, wait for the expected URL, text, or element and inspect the resulting state. For web-app verification, also check relevant console errors and failed network requests.
6. Capture a screenshot when visual layout or appearance is part of the requirement.
7. Call `browser.disable` before asking the user for input, waiting on an external event, or finishing.

## Boundaries

- The in-app browser is isolated from the user's personal Chrome profile. Do not assume it contains existing logins, cookies, or extensions.
- Never inspect cookies or storage unless the task requires it and the user authorized that data access.
- A successful click is not proof of success. Verify the user-visible or application state it was meant to produce.
- Pause before purchases, submissions, messages, deletions, or other irreversible external actions unless the user explicitly authorized that exact action.

## Output

Report the tested URL and flow, the final observed state, and the evidence used. Separate visual, console, and network findings, and state any step that could not be verified.