Skip to main content
Glama
cloudflare

Cloudflare Playwright MCP

Official
by cloudflare

browser_handle_dialog

Destructive

Handle browser dialogs by accepting or inputting text, enabling automated interaction with prompts, alerts, or confirmations during web testing with Playwright and Cloudflare integration.

Instructions

Handle a dialog

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
acceptYesWhether to accept the dialog.
promptTextNoThe text of the prompt in case of a prompt dialog.

Implementation Reference

  • The handler function that finds the current dialog state and either accepts it with optional prompt text or dismisses it, then clears the modal state and returns a code snippet.
    handle: async (context, params) => {
      const dialogState = context.modalStates().find(state => state.type === 'dialog');
      if (!dialogState)
        throw new Error('No dialog visible');
    
      if (params.accept)
        await dialogState.dialog.accept(params.promptText);
      else
        await dialogState.dialog.dismiss();
    
      context.clearModalState(dialogState);
    
      const code = [
        `// <internal code to handle "${dialogState.dialog.type()}" dialog>`,
      ];
    
      return {
        code,
        captureSnapshot,
        waitForNetwork: false,
      };
    },
  • Schema definition for the browser_handle_dialog tool, specifying input parameters 'accept' (boolean) and optional 'promptText' (string), marked as destructive.
    schema: {
      name: 'browser_handle_dialog',
      title: 'Handle a dialog',
      description: 'Handle a dialog',
      inputSchema: z.object({
        accept: z.coerce.boolean().describe('Whether to accept the dialog.'),
        promptText: z.string().optional().describe('The text of the prompt in case of a prompt dialog.'),
      }),
      type: 'destructive',
    },
  • src/tools.ts:35-50 (registration)
    Includes dialogs(true) which registers browser_handle_dialog for snapshot (non-vision) mode.
    export const snapshotTools: Tool<any>[] = [
      ...common(true),
      ...console,
      ...dialogs(true),
      ...files(true),
      ...install,
      ...keyboard(true),
      ...navigate(true),
      ...network,
      ...pdf,
      ...screenshot,
      ...snapshot,
      ...tabs(true),
      ...testing,
      ...wait(true),
    ];
  • src/tools.ts:52-66 (registration)
    Includes dialogs(false) which registers browser_handle_dialog for vision mode.
    export const visionTools: Tool<any>[] = [
      ...common(false),
      ...console,
      ...dialogs(false),
      ...files(false),
      ...install,
      ...keyboard(false),
      ...navigate(false),
      ...network,
      ...pdf,
      ...tabs(false),
      ...testing,
      ...vision,
      ...wait(false),
    ];
Behavior3/5

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

Annotations provide significant behavioral information: destructiveHint=true indicates this performs a potentially destructive action, and openWorldHint=true suggests it operates on external state. The description adds no behavioral context beyond what annotations already declare - it doesn't explain what 'destructive' means in this context (e.g., accepting a dialog might submit data, dismissing might cancel an operation), nor does it mention any side effects, authentication needs, or rate limits. However, it doesn't contradict the annotations either.

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 maximally concise at just three words. It's front-loaded with the core concept and contains zero wasted words or redundant information. While it's under-specified, this isn't a conciseness issue - it efficiently communicates the tool's domain (browser dialogs) without unnecessary elaboration.

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

Completeness2/5

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

For a destructive tool with no output schema and complex behavioral implications, the description is inadequate. It doesn't explain what types of dialogs are handled, what 'handling' entails operationally, what happens after dialog handling, or any error conditions. The annotations provide safety warnings but the description fails to give the agent enough context to use this tool effectively in browser automation workflows.

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%, with both parameters clearly documented in the schema: 'accept' (whether to accept the dialog) and 'promptText' (text for prompt dialogs). The description adds no parameter semantics beyond what the schema already provides. The baseline score of 3 is appropriate since the schema does the heavy lifting of parameter documentation, though the description could have explained the relationship between these parameters (e.g., promptText is only needed for certain dialog types).

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

Purpose2/5

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

The description 'Handle a dialog' is tautological - it essentially restates the tool name 'browser_handle_dialog' without specifying what 'handle' means. While it's clear this relates to browser dialogs, it doesn't distinguish what specific dialog-handling action it performs compared to other browser tools like browser_click or browser_press_key. The description lacks a specific verb-resource combination that clarifies the exact operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There's no mention of what types of dialogs it handles (alerts, confirms, prompts), when it should be invoked during browser automation workflows, or how it relates to other browser interaction tools. The agent must infer usage from the tool name alone, which is insufficient for proper tool selection.

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

Related 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/cloudflare/playwright-mcp'

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