Skip to main content
Glama
livoras

Better Playwright MCP

by livoras

browserHandleDialog

Handle browser dialogs by accepting or prompting responses, specifying wait times, and automating web interactions efficiently using the Better Playwright MCP server.

Instructions

处理浏览器对话框

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
acceptYes是否接受对话框
pageIdYes页面ID
promptTextNo提示对话框的回答文本
waitForTimeoutNo操作后等待获取快照的延迟时间(毫秒,默认2000)

Implementation Reference

  • The core handler function for the 'browser_handle_dialog' tool. It finds the current dialog modal state, clears it, and either accepts or dismisses the dialog based on the 'accept' parameter, optionally providing prompt text.
    handle: async (tab, params, response) => {
        response.setIncludeSnapshot();
        const dialogState = tab.modalStates().find(state => state.type === 'dialog');
        if (!dialogState)
            throw new Error('No dialog visible');
        tab.clearModalState(dialogState);
        await tab.waitForCompletion(async () => {
            if (params.accept)
                await dialogState.dialog.accept(params.promptText);
            else
                await dialogState.dialog.dismiss();
        });
    },
  • Schema definition for the 'browser_handle_dialog' tool, specifying the name, title, description, input parameters (accept boolean and optional promptText), and type as destructive.
    schema: {
        name: 'browser_handle_dialog',
        title: 'Handle a dialog',
        description: 'Handle a dialog',
        inputSchema: z.object({
            accept: z.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',
    },
  • lib/tools.js:32-49 (registration)
    Registration of the browser_handle_dialog tool as part of the aggregated allTools array, which spreads tools from dialogs.js along with other browser tools.
    export const allTools = [
        ...common,
        ...console,
        ...dialogs,
        ...evaluate,
        ...files,
        ...form,
        ...install,
        ...keyboard,
        ...navigate,
        ...network,
        ...mouse,
        ...pdf,
        ...screenshot,
        ...snapshot,
        ...tabs,
        ...wait,
    ];
  • Local registration and definition of the 'browser_handle_dialog' tool using defineTabTool, which wraps it for tab context and modal state handling.
    const handleDialog = defineTabTool({
        capability: 'core',
        schema: {
            name: 'browser_handle_dialog',
            title: 'Handle a dialog',
            description: 'Handle a dialog',
            inputSchema: z.object({
                accept: z.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',
        },
        handle: async (tab, params, response) => {
            response.setIncludeSnapshot();
            const dialogState = tab.modalStates().find(state => state.type === 'dialog');
            if (!dialogState)
                throw new Error('No dialog visible');
            tab.clearModalState(dialogState);
            await tab.waitForCompletion(async () => {
                if (params.accept)
                    await dialogState.dialog.accept(params.promptText);
                else
                    await dialogState.dialog.dismiss();
            });
        },
        clearsModalState: 'dialog',
    });
  • Helper function defineTabTool that wraps tab-based tools like browser_handle_dialog, adding modal state validation before calling the core handler.
    export function defineTabTool(tool) {
        return {
            ...tool,
            handle: async (context, params, response) => {
                const tab = context.currentTabOrDie();
                const modalStates = tab.modalStates().map(state => state.type);
                if (tool.clearsModalState && !modalStates.includes(tool.clearsModalState))
                    response.addError(`Error: The tool "${tool.schema.name}" can only be used when there is related modal state present.\n` + tab.modalStatesMarkdown().join('\n'));
                else if (!tool.clearsModalState && modalStates.length)
                    response.addError(`Error: Tool "${tool.schema.name}" does not handle the modal state.\n` + tab.modalStatesMarkdown().join('\n'));
                else
                    return tool.handle(tab, params, response);
            },
        };
    }
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. '处理' (handle) implies a mutation action on browser dialogs, but it doesn't disclose critical traits: whether it requires specific dialog states, what happens on acceptance vs. dismissal, if it affects page navigation, or potential side effects like page reloads. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 extremely concise with a single phrase '处理浏览器对话框', which is front-loaded and wastes no words. However, this brevity borders on under-specification rather than optimal conciseness, as it omits necessary details for clarity. It earns a 4 for being compact but loses points for not including even minimal operational context.

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?

Given the tool's complexity (handling browser dialogs with mutation), lack of annotations, and no output schema, the description is incomplete. It doesn't cover return values, error conditions (e.g., what if no dialog exists), or integration with sibling tools like waitForSelector for dialog detection. For a 4-parameter tool with behavioral implications, this minimal description fails to provide adequate context for safe and effective use.

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 clear parameter descriptions in the schema (e.g., 'accept' as boolean for dialog acceptance, 'promptText' for response text). The description adds no additional meaning beyond the schema, such as explaining parameter interactions (e.g., 'promptText' is only relevant for prompt dialogs) or default behaviors. Given high schema coverage, the baseline score of 3 is appropriate as the schema adequately documents parameters.

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 browser dialog) is a tautology that essentially restates the tool name 'browserHandleDialog' in Chinese. It doesn't specify what type of browser dialog (alert, confirm, prompt) or what 'handle' means (accept, dismiss, respond). While it distinguishes from siblings like browserClick or browserType by focusing on dialogs, the purpose remains vague without clarifying the specific action.

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?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open page with a dialog), exclusions (e.g., not for non-dialog interactions), or related tools like browserPressKey for keyboard-based dialog handling. The description alone offers no context for appropriate usage scenarios.

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/livoras/better-playwright-mcp'

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