Skip to main content
Glama
andresolbach

nodriver-mcp-server

by andresolbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Handle JavaScript dialog

handle_dialog

Resolve blocking JavaScript alert, confirm, or prompt dialogs by accepting or dismissing them, and optionally entering text for prompt dialogs.

Instructions

Answer an open JavaScript dialog — alert, confirm or prompt.

A dialog blocks the page and every subsequent tool call until it is handled, so call this as soon as one appears. Returns an error if no dialog is open.

beforeunload dialogs triggered by navigating away are handled automatically via navigate_page's handle_before_unload parameter; this tool is for dialogs the page opens by itself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoAccept (OK) or dismiss (Cancel) the dialog. Either closes an alert(); for confirm() the choice is what the page's JavaScript receives.accept
browserNoWhich browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.default
prompt_textNoText to enter into a prompt() dialog before accepting it. Ignored for alert() and confirm() dialogs.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • addedInput schema / properties / browser
      Added value: +{
+  "default": "default",
+  "description": "Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.",
+  "type": "string"
+}
  2. First observedv1.7.2

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds crucial runtime behavior: dialogs block the page and all subsequent tool calls, calling with no open dialog returns an error, and beforeunload dialogs are auto-handled elsewhere. This meaningfully helps an agent predict consequences before invoking the tool.

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 compact and front-loaded: purpose in the first sentence, actionable urgency in the second, and the key exclusion in the third. Every sentence contributes necessary operational information without redundancy.

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?

With a complete parameter schema, clear annotations, and an output schema present, the description provides all essential behavioral context an agent needs. It covers when to call, what happens if unused, error behavior, and the beforeunload exception, leaving no significant gap.

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

Parameters3/5

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

Schema description coverage is 100%, and each parameter already has a detailed description, so the baseline is 3. The tool description itself does not add further parameter-level detail beyond what the schema already provides.

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 uses a specific verb ('Answer') with a specific resource ('an open JavaScript dialog — alert, confirm or prompt'), immediately clarifying what the tool acts on. It also distinguishes itself from beforeunload handling by pointing to navigate_page, which separates it from related navigation 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?

The description explicitly says to call this tool as soon as a dialog appears, warns that it blocks subsequent calls, and states that an error is returned if no dialog is open. It also draws a clear boundary: beforeunload dialogs are handled by navigate_page's parameter, so this tool is only for page-initiated dialogs.

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