Computer Use

Overview Schema Source Related Servers Discussions Admin

Answer JavaScript dialog

browser_handle_dialog

Destructive

Accept or dismiss JavaScript alert, confirm, and prompt dialogs open in an agent tab, optionally entering prompt text, so paused browser pages can continue.

Instructions

Answer the JavaScript dialog (alert, confirm, prompt or leave-page) open in one of the agent's tabs. While one is open the page is paused: browser_snapshot shows the dialog's type, message and dialog_id instead of the page, and other browser commands on the tab say a dialog is open. accept presses OK and dismiss presses Cancel. prompt_text is entered into a prompt before accepting it; without it, a prompt is accepted with its default text. Pass the dialog_id from the snapshot, so a dialog that replaced the one you read is refused instead of answered. Works on a background tab without showing it or using the keyboard. A dialog that opened before the agent attached to the tab cannot be seen or answered; the user answers that one in Chrome. Accepting a confirm can submit, delete or leave a page with unsaved changes, so read the message, and ask the user before confirming anything irreversible.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tab_id": "<tab_id>",
      "action": "<action>"
    },
    "name": "browser_handle_dialog"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	accept (OK) or dismiss (Cancel)
`tab_id`	Yes	tab_id of one of the agent's tabs, from browser_open_tab or browser_list_tabs
`dialog_id`	No	dialog_id of the dialog being answered, from browser_snapshot (such as d3). A different dialog open now is refused instead of answered
`session_id`	No	Stable task or thread ID. Pass the same value on every browser call for this task. Different IDs isolate tabs and cleanup within one MCP process. Omit for the default process session.
`prompt_text`	No	Text to enter into a prompt dialog before accepting it. Only with action=accept on a prompt

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.13.0Nov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: the page is paused, browser_snapshot exposes the dialog, other commands report an open dialog, accept and dismiss map to OK and Cancel, prompt_text is entered before accepting, and the operation works on a background tab without keyboard focus. It also discloses important failure and safety behavior, such as refusing a mismatched dialog_id and the potential for confirm to submit, delete, or leave unsaved changes.

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

Conciseness4/5

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

The description is front-loaded with the core action and behavior, and most sentences provide distinct technical or safety information. It is dense but not wasteful, though a few operational details could be tightened without losing meaning.

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, lack of an output schema, and potentially destructive behavior, the description is complete enough for an agent to call it correctly. It covers dialog recognition, parameter usage, stale-dialog protection, background-tab behavior, pre-attach limitations, and irreversible-action warnings.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all five parameters. The description still adds useful meaning by explaining accept/dismiss behavior, that prompt_text is entered before accepting, and that a prompt is accepted with default text if prompt_text is omitted.

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?

The description starts with a specific verb and resource: answer the JavaScript dialog (alert, confirm, prompt or leave-page) open in one of the agent's tabs. It clearly distinguishes this action from siblings by explaining that browser_snapshot displays dialog details and other browser commands report that a dialog is open.

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 gives explicit guidance on when and how to use the tool, including passing dialog_id from browser_snapshot to avoid answering a replacement dialog. It also states when the tool cannot be used—dialogs opened before the agent attached cannot be seen or answered—and warns to ask the user before confirming irreversible actions.

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