Skip to main content
Glama
icueth

browser-for-ai

by icueth
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

browser_launch

Launch a new browser session or attach to an existing Chrome debug port. Control the URL, viewport, device mode, and isolation for automated web interaction.

Instructions

Open a browser session. Choose the mode by what the task needs: • mode:"fresh" (default choice) — launch our own throwaway Chrome; add incognito:true for a clean slate. Best for reverse-engineering a public flow or any site that does NOT need your existing login. No setup. • mode:"attach" — connect to a Chrome the user already started with a debug port (default 9222). Use when you need REAL logins/cookies, or a human-looking browser (navigator.webdriver=false, real profile & fingerprint, passes basic bot checks). Requires starting Chrome first: ./bfa-chrome 9222 (Chrome 136+ needs a non-default profile — bfa-chrome handles that). You canNOT attach to an already-open normal Chrome; it has no debug port. Multiple concurrent sessions are supported. In attach mode only port is used — profile, headless, incognito applies to fresh mode only. The session you launch becomes the ACTIVE one (tools without sessionId target it). In fresh mode bfa auto-follows a tab the page opens (so a game that launches in a new window keeps being driven); use browser_use_tab to switch manually. For phone/PG games pass device:"mobile" for a stable viewport.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNooptional URL to open immediately
modeYesfresh = launch our own; attach = connect to a debug-port Chrome
portNoattach: Chrome remote-debugging port (default 9222)
deviceNodevice preset. "mobile" = a STABLE 390x844 phone viewport (dpr 3, mobile layout + iPhone UA) that does not track the OS window, so it never self-shrinks and your click coordinates stay put — use this for phone/PG-style games. "desktop" = 1280x800. Overridden by an explicit `viewport`.
profileNofresh: profile name under ~/.bfa/profiles
headlessNofresh: run headless (default false)
viewportNopage viewport. Default is 800x600 landscape, which letterboxes PORTRAIT canvas/WebGL games (Cocos) and lets their full-screen overlay swallow coordinate clicks. Set e.g. {width:390,height:844} so the canvas fills the viewport and page_click_at lands on the game. Keep hasTouch:false (default) so mouse clicks drive games that listen for mouse input.
incognitoNofresh: isolated context with no prior state

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden, and it excels: it discloses that fresh is a throwaway browser, attach connects to a debug-port Chrome, the launched session becomes active, fresh mode auto-follows new tabs, and only `port` applies in attach mode. It also reveals technical details like navigator.webdriver=false and viewport stability for mobile games.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured with scannable bullets and front-loaded mode guidance. Every sentence adds operational value, including concurrency, active-session behavior, and mobile-game advice, without unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, eight parameters, and no output schema or annotations, the description covers the essential operational context: how to select modes, prerequisites, limitations, session behavior, and game-specific guidance. An agent has enough information to invoke the tool correctly without additional research.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaning beyond the schema: it explains mode-specific parameter applicability, the default port, why `device:'mobile'` matters for games, and how `viewport` interacts with canvas/WebGL letterboxing. This materially improves an agent's ability to choose correct parameter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Open a browser session') and clearly differentiates the two modes it supports, fresh vs attach. The description makes it unambiguous what the tool does and how it differs from later navigation/session tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: fresh for public flows or sites not needing login, attach for real logins/cookies or human-like browser behavior. It also gives exclusions and prerequisites, such as 'You canNOT attach to an already-open normal Chrome' and needing `./bfa-chrome 9222` first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools