Lists pending browser dialogs or accepts and dismisses a specific dialog, optionally supplying prompt text, to handle blocking alerts and prompts during automation.
List pending dialogs or accept/dismiss one dialog.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| accept | No | ||
| pageId | No | Defaults to the active page | |
| dismiss | No | ||
| sessionId | No | Defaults to the active session | |
| promptText | No |
Changes observed during successful MCP inspections.
v2026.10.24Input schema / properties / pageId / descriptionPrevious value: -"Stable page ID; defaults to the session active page"New value: +"Defaults to the active page"Input schema / properties / sessionId / descriptionPrevious value: -"Optional session ID; defaults to this MCP client active session"New value: +"Defaults to the active session"v2026.8.14Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It says dialogs can be listed or accepted/dismissed, but does not explain whether dialogs block page execution, what dialog types are involved, how promptText applies, whether accepting is irreversible, or what happens if a dialog is absent or already handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single short sentence with no filler and is appropriately front-loaded. It is concise, though the terseness contributes to the missing behavioral and parameter detail rather than being complemented elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and incomplete parameter documentation, the description is not complete enough for a 6-parameter browser dialog tool. It does not explain what a listing returns, how to identify the target dialog, or the consequences of accept/dismiss decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 6 parameters and only 33% schema description coverage, so the description should compensate but does not. It mentions accept/dismiss conceptually but gives no meaning for id, promptText, or the interaction between accept, dismiss, and id, leaving most parameter semantics to be inferred.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (dialogs) and two concrete operations: list pending dialogs, or accept/dismiss one dialog. It is clear enough for an agent to understand the tool's purpose, though the dual-mode nature is only briefly framed and no sibling tools cover this exact dialog-handling domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming two modes, but it does not explain when to list versus when to accept/dismiss, what prerequisites are needed (such as a dialog id), or how these operations relate to browser interaction siblings like click or press_key. It provides a minimum viable indication of usage without explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.