browser-control

# 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. Perform the smallest meaningful action. Use `fill` when replacing a field and `type` only when appending is intended. 5. After every navigation or state-changing action, 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 i...