Skip to main content
Glama

dialog_auto_handle

Auto-handle native browser dialogs (alerts, confirms, prompts, beforeunload) with persistent accept/dismiss settings. Update action, types, or disable without re-arming.

Instructions

⭐ Install a PERSISTENT auto-handler for native browser dialogs. Unlike dialog_handle (one-shot, action baked in at arm time), this one stays armed across many dialogs and reads its config at fire time — call again with new action/types to update without re-arming.

Args:
    action: "accept" (Leave / OK) or "dismiss" (Cancel / Stay)
    enabled: True to arm, False to disable (config preserved)
    types: optional list to scope handling — any of:
           ["alert", "confirm", "prompt", "beforeunload"]
           None (default) = handle all types.
    text: prompt response when action="accept" on prompt() dialogs;
          also basic-auth "user:pass" for HTTP 401.

Common patterns:
    # Form pages with "unsaved changes" guard — auto-leave forever
    dialog_auto_handle(action="accept", types=["beforeunload"])

    # Pages that spam alert() — auto-OK
    dialog_auto_handle(action="accept", types=["alert"])

    # Disable when done
    dialog_auto_handle(enabled=False)

Native dialogs only (Chrome's own card UI). HTML/CSS modal overlays
are regular DOM — use click_text("Cancel") / click_role for those.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoaccept
enabledNo
typesNo
textNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

No annotations, so description carries full burden. Describes persistence across dialogs, config read at fire time, update without re-arming, and limitation to native dialogs. Missing potential side effects, but behavior is well detailed.

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?

Front-loaded with key info, uses bullet points and examples. Slightly long but each sentence adds value. Could be trimmed, but structure is clear.

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 no annotations and 4 params, description covers usage patterns, limitations (native only), and parameter details. Output schema exists but not needed per rules. Provides enough for agent to use correctly.

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?

Schema coverage is 0% so description must explain all 4 params. It does: action (accept/dismiss), enabled (arm/disable), types (scoping list, default all), text (prompt response or basic auth). Adds meaning beyond schema defaults.

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 clearly states it installs a persistent auto-handler for native browser dialogs, using specific verb 'install' and resource 'auto-handler'. It distinguishes from sibling dialog_handle (one-shot vs persistent).

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?

Explicitly contrasts with dialog_handle for one-shot use, provides contextual patterns (form unsaved changes, alert spam) and when to disable via enabled=False. Lists alternatives for HTML overlays.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RobithYusuf/mcp-stealth-chrome'

If you have feedback or need assistance with the MCP directory API, please join our Discord server