Browser Automation Capability
When to Use
Use this capability for opening pages, navigating web apps, clicking UI, filling forms, taking screenshots, testing landing pages, checking responsive behavior, and verifying served frontend behavior.
Preferred Implementation
- Chrome DevTools MCP (
chrome-devtools-mcp): Use the chrome-devtools MCP server tools (e.g., chrome-devtools/navigate_page, chrome-devtools/click, chrome-devtools/take_screenshot) as the primary method for browser automation.
- Responsive Testing: Always use
chrome-devtools/emulate or chrome-devtools/resize_page to verify page layouts using a mobile-view first approach.
- Performance & QA: Use performance tracing or Lighthouse audits to verify loading speed.
- Credential Safety: Ensure that browser sessions do not cache sensitive credentials (e.g., run the server with
--isolated or avoid saving cookies/auth headers in public scopes) to prevent credential leaks.
- Use programmatic scripts (e.g., Puppeteer, Playwright) or in-app connectors when repeatable, custom QA flows are required.
- Use OS-level Computer Use only as a last resort if standard API/protocol-based automation fails.
Inputs
- URL or local file path.
- Objective.
- Viewport/device targets.
- Allowed actions.
- Credentials policy and login state.
- Expected evidence: screenshot, notes, or test result.
Outputs
- Browser QA Report.
- Screenshots or visual findings.
- Interaction log.
- Broken links, console errors, layout issues, or accessibility concerns.
- Recommendation and next action.
Security and Ethics
- Do not enter secrets unless the user explicitly approves a secure login flow.
- Do not expose cookies, tokens, private URLs, or account details in reports.
- Treat public frontend, browser JavaScript, and public assets as non-secret surfaces.
1---2name: browser-automation3description: Browser Automation Capability4---5# Browser Automation Capability67## When to Use89Use this capability for opening pages, navigating web apps, clicking UI, filling forms, taking screenshots, testing landing pages, checking responsive behavior, and verifying served frontend behavior.1011## Preferred Implementation1213- **Chrome DevTools MCP (`chrome-devtools-mcp`):** Use the `chrome-devtools` MCP server tools (e.g., `chrome-devtools/navigate_page`, `chrome-devtools/click`, `chrome-devtools/take_screenshot`) as the primary method for browser automation.14 - **Responsive Testing:** Always use `chrome-devtools/emulate` or `chrome-devtools/resize_page` to verify page layouts using a **mobile-view first** approach.15 - **Performance & QA:** Use performance tracing or Lighthouse audits to verify loading speed.16 - **Credential Safety:** Ensure that browser sessions do not cache sensitive credentials (e.g., run the server with `--isolated` or avoid saving cookies/auth headers in public scopes) to prevent credential leaks.17- Use programmatic scripts (e.g., Puppeteer, Playwright) or in-app connectors when repeatable, custom QA flows are required.18- Use OS-level Computer Use only as a last resort if standard API/protocol-based automation fails.1920## Inputs2122- URL or local file path.23- Objective.24- Viewport/device targets.25- Allowed actions.26- Credentials policy and login state.27- Expected evidence: screenshot, notes, or test result.2829## Outputs3031- Browser QA Report.32- Screenshots or visual findings.33- Interaction log.34- Broken links, console errors, layout issues, or accessibility concerns.35- Recommendation and next action.3637## Security and Ethics3839- Do not enter secrets unless the user explicitly approves a secure login flow.40- Do not expose cookies, tokens, private URLs, or account details in reports.41- Treat public frontend, browser JavaScript, and public assets as non-secret surfaces.
lensetek