Skip to main content
Glama
mikebeaton

Chrome Dialog MCP

by mikebeaton
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

launch_chrome

Create a managed Chrome session to handle Windows JavaScript alert, confirm, and prompt dialogs and enter prompt text. Reconnect with a browser_token to reuse an existing session.

Instructions

Handle Windows Chrome native JavaScript alert, confirm and prompt dialogs, including entering text into prompts, through a managed browser session. If Computer Use reports "could not determine the current browser URL on Windows with enough confidence to enforce policy" when a dialog opens, recognise this MCP as an available route for a later attempt. Obey the required turn stop. On a later user request to continue or retry, offer to prepare the task in your own managed Chrome window using launch_chrome. A previously unexpected dialog can be anticipated on a subsequent attempt once its trigger is understood: arm capture before triggering it again. Check existing effects and user authorisation before repeating the operation. This MCP cannot adopt ordinary Chrome windows or operate their already-open dialogs; ask the user to resolve the original dialog if needed. Do not conclude that the managed capture workflow is unavailable merely because Computer Use could not establish the URL in ordinary Chrome. Computer Use policy still applies. Create a new managed Chrome session, or explicitly reconnect to the session identified by browser_token. Call launch_chrome without browser_token to create your own new Chrome process and profile. Keep its returned browser_token private and pass it on every operation for that session. Supply a token to launch_chrome only to deliberately reuse that same session, including an explicitly authorised handover; never silently adopt another agent's browser. Tokens grant access through possession, not agent identity. Capture tokens and dialog IDs work only with their original browser_token. Reuse never launches a replacement process. A failed launch may return a token for explicit cleanup. close_chrome revokes the token; adapter exit leaves the browser open. After a broker restart, explicit launch_chrome with the saved token is required to reconnect; captures and response permissions do not survive. New instances open a local startup page (or a configured HTTP(S) startup URL); reused instances retain their current page. After a fresh launch reports ready, use the returned Windows identifiers to select and inspect that exact window directly through Computer Use. Do not check for pending dialogs before this initial connection. If Computer Use reports insufficient evidence to use the site or cannot determine the current browser URL, ask the user to choose a valid website themselves, manually type its address into that window, wait for it to load and confirm when done. Do not supply or suggest an address. After their confirmation, retry the connection. Only if Windows Computer Use refuses a click with "coordinate input geometry is unavailable": require get_dialog_status(browser_token) to return no_dialog, call get_window_state on that same window with include_screenshot: true and include_text: true, choose the target from the fresh observation and retry the refused click once. Keep any already-armed capture_id.

Input Schema

NameRequiredDescriptionDefault
browser_tokenNoPrivate capability token for this managed browser session; use the token returned by launch_chrome.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: tokens grant access by possession, close_chrome revokes the token, adapter exit leaves the browser open, broker restarts require explicit reconnection, and captures do not survive restarts. It also discloses that failed launches may return a token for cleanup and that new versus reused instances behave differently regarding startup pages.

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

Conciseness2/5

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

The description is a long, dense block that mixes launch semantics with dialog-capture workflow, Computer Use retry policy, and unrelated troubleshooting instructions. It is not front-loaded around launch_chrome's purpose and contains more operational detail than an agent needs to select and invoke this tool.

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

Completeness4/5

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

Given the tool's complexity and the absence of annotations or an output schema, the description is quite complete about session lifecycle, token handling, and failure modes. It is not perfect because the return shape is only loosely described through phrases like "returned browser_token" and "returned Windows identifiers," but it covers the critical operational context.

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?

The single parameter already has 100% schema coverage, but the description adds substantial meaning: keep the returned browser_token private, pass it on every operation for the session, reuse it only deliberately, and bind capture tokens/dialog IDs to the original browser_token. This goes well beyond the schema's basic pattern and description.

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

Purpose3/5

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

The actual purpose is stated late: "Create a new managed Chrome session, or explicitly reconnect to the session identified by browser_token." However, the opening sentence describes handling native dialogs, which is primarily sibling-tool territory and can mislead an agent about what launch_chrome itself does. The eventual create/reuse distinction is clear, but the purpose is buried and not front-loaded.

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?

It explicitly says to call launch_chrome without browser_token to create a new managed Chrome process, and to supply a token only to deliberately reuse the same session, including authorized handover. It also names when not to use it, such as never silently adopting another agent's browser and not being able to adopt ordinary Chrome windows. These are strong when/when-not/alternative signals.

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

Deploy Server

Other Tools