Skip to main content
Glama
phishark-git

PhiShark Playwright MCP

by phishark-git
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

PhiShark Playwright MCP

This repository is a deliberately thin fork of Microsoft Playwright MCP. It keeps the upstream Playwright browser engine, MCP protocol, tools, and capabilities, then adds PhiShark checks around navigation:

  • Every main-frame URL and redirect is checked with PhiShark preflight before the document is loaded.

  • The page Playwright actually loaded is captured once and sent to PhiShark browser-deep; no second web fetcher is used.

  • Safe/low pages work normally, medium pages carry a warning, high/critical pages are blocked, and unavailable scans place the page in read-only mode.

  • phishark_security_status and phishark_rescan expose the current policy state without providing a risk bypass.

This is a phishing and page-risk layer. It is not a Chromium sandbox, malware isolation boundary, or prompt-injection defense. Persistent, CDP, remote, and Playwright Chrome Bridge modes retain upstream compatibility but can expose existing browser sessions before browser-deep finishes. Isolated mode is the default.

Requirements

  • Node.js 22 or newer

  • A PhiShark public API key with preflight and browser-deep access

  • An MCP client supported by upstream Playwright MCP

Quick start

Pass the API key through the MCP process environment; never put it in tool arguments:

{
  "mcpServers": {
    "phishark-playwright": {
      "command": "npx",
      "args": ["-y", "@phishark/playwright-mcp@latest"],
      "env": {
        "PHISHARK_API_KEY": "<your PhiShark public API key>"
      }
    }
  }
}

Optional environment configuration:

Name

Default

Purpose

PHISHARK_API_BASE_URL

https://api.phishark.io

Public API base URL; override only for test/non-production.

PHISHARK_PREFLIGHT_TIMEOUT_MS

10000

Synchronous preflight deadline.

PHISHARK_BROWSER_DEEP_TIMEOUT_MS

20000

Synchronous browser-deep deadline.

PHISHARK_PREFLIGHT_CACHE_TTL_MS

600000

Canonical full-URL cache TTL.

PHISHARK_BROWSER_DEEP_CACHE_TTL_MS

120000

Final URL and evidence-hash cache TTL.

PHISHARK_ALLOW_PRIVATE_NETWORK

false

Explicitly allow localhost/private/link-local browsing.

Use --phishark-persistent to opt into upstream's default persistent browser profile. Existing --extension, CDP, remote, and configuration-file modes are also preserved and print a session-risk notice when they are not isolated.

Upstream Playwright MCP documentation

A Model Context Protocol (MCP) server that provides browser automation capabilities using Playwright. This server enables LLMs to interact with web pages through structured accessibility snapshots, bypassing the need for screenshots or visually-tuned models.

Playwright MCP vs Playwright CLI

This package provides MCP interface into Playwright. If you are using a coding agent, you might benefit from using the CLI+SKILLS instead.

  • CLI: Modern coding agents increasingly favor CLI–based workflows exposed as SKILLs over MCP because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context, allowing agents to act through concise, purpose-built commands. This makes CLI + SKILLs better suited for high-throughput coding agents that must balance browser automation with large codebases, tests, and reasoning within limited context windows.Learn more about Playwright CLI with SKILLS.

  • MCP: MCP remains relevant for specialized agentic loops that benefit from persistent state, rich introspection, and iterative reasoning over page structure, such as exploratory automation, self-healing tests, or long-running autonomous workflows where maintaining continuous browser context outweighs token cost concerns.

Key Features

  • Fast and lightweight. Uses Playwright's accessibility tree, not pixel-based input.

  • LLM-friendly. No vision models needed, operates purely on structured data.

  • Deterministic tool application. Avoids ambiguity common with screenshot-based approaches.

Getting started

First, install the Playwright MCP server with your client.

Standard config works in most of the tools:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@phishark/playwright-mcp@latest"
      ]
    }
  }
}

Add via the Amp VS Code extension settings screen or by updating your settings.json file:

"amp.mcpServers": {
  "playwright": {
    "command": "npx",
    "args": [
      "@phishark/playwright-mcp@latest"
    ]
  }
}

Amp CLI Setup:

Add via the amp mcp add command below

amp mcp add playwright -- npx @phishark/playwright-mcp@latest

Add via the Antigravity settings or by updating your configuration file:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@phishark/playwright-mcp@latest"
      ]
    }
  }
}

Use the Claude Code CLI to add the Playwright MCP server:

claude mcp add playwright npx @phishark/playwright-mcp@latest

Follow the MCP install guide, use the standard config above.

Follow the instruction in the section Configuring MCP Servers

Example: Local Setup

Add the following to your cline_mcp_settings.json file:

{
  "mcpServers": {
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "timeout": 30,
      "args": [
        "-y",
        "@phishark/playwright-mcp@latest"
      ],
      "disabled": false
    }
  }
}

Use the Codex CLI to add the Playwright MCP server:

codex mcp add playwright npx "@phishark/playwright-mcp@latest"

Alternatively, create or edit the configuration file ~/.codex/config.toml and add:

[mcp_servers.playwright]
command = "npx"
args = ["@phishark/playwright-mcp@latest"]

For more information, see the Codex MCP documentation.

Use the Copilot CLI to interactively add the Playwright MCP server:

/mcp add

Alternatively, create or edit the configuration file ~/.copilot/mcp-config.json and add:

{
  "mcpServers": {
    "playwright": {
      "type": "local",
      "command": "npx",
      "tools": [
        "*"
      ],
      "args": [
        "@phishark/playwright-mcp@latest"
      ]
    }
  }
}

For more information, see the Copilot CLI documentation.

Click the button to install:

Or install manually:

Go to Cursor Settings -> MCP -> Add new MCP Server. Name to your liking, use command type with the command npx @phishark/playwright-mcp@latest. You can also verify config or add command like arguments via clicking Edit.

Use the Factory CLI to add the Playwright MCP server:

droid mcp add playwright "npx @phishark/playwright-mcp@latest"

Alternatively, type /mcp within Factory droid to open an interactive UI for managing MCP servers.

For more information, see the Factory MCP documentation.

Follow the MCP install guide, use the standard config above.

Click the button to install:

Install in Goose

Or install manually:

Go to Advanced settings -> Extensions -> Add custom extension. Name to your liking, use type STDIO, and set the command to npx @phishark/playwright-mcp. Click "Add Extension".

Use the Grok CLI to add the Playwright MCP server:

grok mcp add playwright -- npx @phishark/playwright-mcp@latest

Alternatively, create or edit the configuration file ~/.grok/config.toml and add:

[mcp_servers.playwright]
command = "npx"
args = ["@phishark/playwright-mcp@latest"]

For more information, see the Grok MCP documentation.

To add the Playwright MCP server in Junie CLI:

  1. Type /mcp

  2. Press Ctrl+A to add a new MCP server

  3. Select Playwright from the list

Alternatively, add to .junie/mcp/mcp.json:

{
  "mcpServers": {
    "Playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@phishark/playwright-mcp@latest"
      ]
    }
  }
}

For more information, see the Junie MCP configuration documentation.

Add to Kiro

Follow the MCP Servers documentation. For example in .kiro/settings/mcp.json:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@phishark/playwright-mcp@latest"
      ]
    }
  }
}

Click the button to install:

Add MCP Server playwright to LM Studio

Or install manually:

Go to Program in the right sidebar -> Install -> Edit mcp.json. Use the standard config above.

Follow the MCP Servers documentation. For example in ~/.config/opencode/opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "playwright": {
      "type": "local",
      "command": [
        "npx",
        "@phishark/playwright-mcp@latest"
      ],
      "enabled": true
    }
  }
}

Open Qodo Gen chat panel in VSCode or IntelliJ → Connect more tools → + Add new MCP → Paste the standard config above.

Click Save.

Click the button to install:

Or install manually:

Follow the MCP install guide, use the standard config above. You can also install the Playwright MCP server using the VS Code CLI:

# For VS Code
code --add-mcp '{"name":"playwright","command":"npx","args":["@phishark/playwright-mcp@latest"]}'

After installation, the Playwright MCP server will be available for use with your GitHub Copilot agent in VS Code.

Go to Settings -> AI -> Manage MCP Servers -> + Add to add an MCP Server. Use the standard config above.

Alternatively, use the slash command /add-mcp in the Warp prompt and paste the standard config from above:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@phishark/playwright-mcp@latest"
      ]
    }
  }
}

Follow Windsurf MCP documentation. Use the standard config above.

Configuration

Playwright MCP server supports following arguments. They can be provided in the JSON configuration above, as a part of the "args" list:

Option

Description

--allowed-hosts <hosts...>

comma-separated list of hosts this server is allowed to serve from. Defaults to the host the server is bound to. Pass '*' to disable the host check.env PLAYWRIGHT_MCP_ALLOWED_HOSTS

--allowed-origins

semicolon-separated list of TRUSTED origins to allow the browser to request. Default is to allow all. Important: does not serve as a security boundary and does not affect redirects.env PLAYWRIGHT_MCP_ALLOWED_ORIGINS

--allow-unrestricted-file-access

allow access to files outside of the workspace roots. Also allows unrestricted access to file:// URLs. By default access to file system is restricted to workspace root directories (or cwd if no roots are configured) only, and navigation to file:// URLs is blocked.env PLAYWRIGHT_MCP_ALLOW_UNRESTRICTED_FILE_ACCESS

--blocked-origins

semicolon-separated list of origins to block the browser from requesting. Blocklist is evaluated before allowlist. If used without the allowlist, requests not matching the blocklist are still allowed. Important: does not serve as a security boundary and does not affect redirects.env PLAYWRIGHT_MCP_BLOCKED_ORIGINS

--block-service-workers

block service workersenv PLAYWRIGHT_MCP_BLOCK_SERVICE_WORKERS

--browser

browser or chrome channel to use, possible values: chrome, firefox, webkit, msedge.env PLAYWRIGHT_MCP_BROWSER

--caps

comma-separated list of additional capabilities to enable, possible values: vision, pdf, devtools.env PLAYWRIGHT_MCP_CAPS

--cdp-endpoint

CDP endpoint to connect to.env PLAYWRIGHT_MCP_CDP_ENDPOINT

--cdp-header <headers...>

CDP headers to send with the connect request, multiple can be specified.env PLAYWRIGHT_MCP_CDP_HEADERS

--cdp-timeout

timeout in milliseconds for connecting to CDP endpoint, defaults to 30000msenv PLAYWRIGHT_MCP_CDP_TIMEOUT

--codegen

specify the language to use for code generation, possible values: "typescript", "none". Default is "typescript".env PLAYWRIGHT_MCP_CODEGEN

--config

path to the configuration file.env PLAYWRIGHT_MCP_CONFIG

--console-level

level of console messages to return: "error", "warning", "info", "debug". Each level includes the messages of more severe levels.env PLAYWRIGHT_MCP_CONSOLE_LEVEL

--device

device to emulate, for example: "iPhone 15"env PLAYWRIGHT_MCP_DEVICE

--mobile

emulate a generic mobile device (Pixel 10 for Chromium, iPhone 17 for WebKit). Mobile pages are usually lighter, which saves tokens. Cannot be combined with --device.env PLAYWRIGHT_MCP_MOBILE

--executable-path

path to the browser executable.env PLAYWRIGHT_MCP_EXECUTABLE_PATH

--extension

Connect to a running browser instance (Edge/Chrome only). Requires the "Playwright Extension" to be installed.env PLAYWRIGHT_MCP_EXTENSION

--endpoint

Bound browser endpoint to connect to.env PLAYWRIGHT_MCP_ENDPOINT

--grant-permissions <permissions...>

List of permissions to grant to the browser context, for example "geolocation", "clipboard-read", "clipboard-write".env PLAYWRIGHT_MCP_GRANT_PERMISSIONS

--headless

run browser in headless mode, headed by defaultenv PLAYWRIGHT_MCP_HEADLESS

--host

host to bind server to. Default is localhost. Use 0.0.0.0 to bind to all interfaces.env PLAYWRIGHT_MCP_HOST

--ignore-https-errors

ignore https errorsenv PLAYWRIGHT_MCP_IGNORE_HTTPS_ERRORS

--init-page <path...>

path to TypeScript file to evaluate on Playwright page objectenv PLAYWRIGHT_MCP_INIT_PAGE

--init-script <path...>

path to JavaScript file to add as an initialization script. The script will be evaluated in every page before any of the page's scripts. Can be specified multiple times.env PLAYWRIGHT_MCP_INIT_SCRIPT

--isolated

keep the browser profile in memory, do not save it to disk.env PLAYWRIGHT_MCP_ISOLATED

--image-responses

whether to send image responses to the client. Can be "allow" or "omit", Defaults to "allow".env PLAYWRIGHT_MCP_IMAGE_RESPONSES

--no-sandbox

disable the sandbox for all process types that are normally sandboxed.env PLAYWRIGHT_MCP_NO_SANDBOX

--output-dir

path to the directory for output files.env PLAYWRIGHT_MCP_OUTPUT_DIR

--output-max-size

Threshold for evicting old output files, in bytes.env PLAYWRIGHT_MCP_OUTPUT_MAX_SIZE

--output-mode

whether to save snapshots, console messages, network logs to a file or to the standard output. Can be "file" or "stdout". Default is "stdout".env PLAYWRIGHT_MCP_OUTPUT_MODE

--port

port to listen on for SSE transport.env PLAYWRIGHT_MCP_PORT

--proxy-bypass

comma-separated domains to bypass proxy, for example ".com,chromium.org,.domain.com"env PLAYWRIGHT_MCP_PROXY_BYPASS

--proxy-server

specify proxy server, for example "http://myproxy:3128" or "socks5://myproxy:8080"env PLAYWRIGHT_MCP_PROXY_SERVER

--sandbox

enable the sandbox for all process types that are normally not sandboxed.env PLAYWRIGHT_MCP_SANDBOX

--save-session

Whether to save the Playwright MCP session into the output directory.env PLAYWRIGHT_MCP_SAVE_SESSION

--secrets

path to a file containing secrets in the dotenv formatenv PLAYWRIGHT_MCP_SECRETS_FILE

--shared-browser-context

reuse the same browser context between all connected HTTP clients.env PLAYWRIGHT_MCP_SHARED_BROWSER_CONTEXT

--snapshot-mode

when taking snapshots for responses, specifies the mode to use. Can be "full" or "none". Default is "full".env PLAYWRIGHT_MCP_SNAPSHOT_MODE

--storage-state

path to the storage state file for isolated sessions.env PLAYWRIGHT_MCP_STORAGE_STATE

--test-id-attribute

specify the attribute to use for test ids, defaults to "data-testid"env PLAYWRIGHT_MCP_TEST_ID_ATTRIBUTE

--timeout-action

specify action timeout in milliseconds, defaults to 5000msenv PLAYWRIGHT_MCP_TIMEOUT_ACTION

--timeout-navigation

specify navigation timeout in milliseconds, defaults to 60000msenv PLAYWRIGHT_MCP_TIMEOUT_NAVIGATION

--user-agent

specify user agent stringenv PLAYWRIGHT_MCP_USER_AGENT

--user-data-dir

path to the user data directory. If not specified, a temporary directory will be created.env PLAYWRIGHT_MCP_USER_DATA_DIR

--viewport-size

specify browser viewport size in pixels, for example "1280x720"env PLAYWRIGHT_MCP_VIEWPORT_SIZE

User profile

PhiShark Playwright MCP uses isolated contexts by default. Persistent profiles and the browser extension remain available as explicit opt-ins and display an elevated-risk warning because existing cookies and signed-in sessions can be exposed to a page before its browser-deep verdict is available.

Persistent profile

All the logged in information will be stored in the persistent profile, you can delete it between sessions if you'd like to clear the offline state. Persistent profile is located at the following locations and you can override it with the --user-data-dir argument.

# Windows
%USERPROFILE%\AppData\Local\ms-playwright\mcp-{channel}-{workspace-hash}

# macOS
- ~/Library/Caches/ms-playwright/mcp-{channel}-{workspace-hash}

# Linux
- ~/.cache/ms-playwright/mcp-{channel}-{workspace-hash}

{workspace-hash} is derived from the MCP client's workspace root, so different projects get separate profiles automatically.

IMPORTANT

A persistent profile can only be used by one browser instance at a time, so concurrent MCP clients sharing the same workspace will conflict. To run several clients in parallel, start each additional client with--isolated or point it at a distinct --user-data-dir.

Isolated

In the isolated mode, each session is started in the isolated profile. Every time you ask MCP to close the browser, the session is closed and all the storage state for this session is lost. You can provide initial storage state to the browser via the config's contextOptions or via the --storage-state argument. Learn more about the storage state here.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@phishark/playwright-mcp@latest",
        "--isolated",
        "--storage-state={path/to/storage.json}"
      ]
    }
  }
}

Browser Extension

The Playwright MCP Chrome Extension allows you to connect to existing browser tabs and leverage your logged-in sessions and browser state. See microsoft/playwright › packages/extension for installation and setup instructions.

Initial state

There are multiple ways to provide the initial state to the browser context or a page.

For the storage state, you can either:

  • Start with a user data directory using the --user-data-dir argument. This will persist all browser data between the sessions.

  • Start with a storage state file using the --storage-state argument. This will load cookies and local storage from the file into an isolated browser context.

For the page state, you can use:

  • --init-page to point to a TypeScript file that will be evaluated on the Playwright page object. This allows you to run arbitrary code to set up the page.

// init-page.ts
export default async ({ page }) => {
  await page.context().grantPermissions(['geolocation']);
  await page.context().setGeolocation({ latitude: 37.7749, longitude: -122.4194 });
  await page.setViewportSize({ width: 1280, height: 720 });
};

  • --init-script to point to a JavaScript file that will be added as an initialization script. The script will be evaluated in every page before any of the page's scripts. This is useful for overriding browser APIs or setting up the environment.

// init-script.js
window.isPlaywrightMCP = true;

Configuration file

The Playwright MCP server can be configured using a JSON configuration file. You can specify the configuration file using the --config command line option:

npx @phishark/playwright-mcp@latest --config path/to/config.json
{
  /**
   * The browser to use.
   */
  browser?: {
    /**
     * The type of browser to use.
     */
    browserName?: 'chromium' | 'firefox' | 'webkit';

    /**
     * Keep the browser profile in memory, do not save it to disk.
     */
    isolated?: boolean;

    /**
     * Path to a user data directory for browser profile persistence.
     * Temporary directory is created by default.
     */
    userDataDir?: string;

    /**
     * Launch options passed to
     * @see https://playwright.dev/docs/api/class-browsertype#browser-type-launch-persistent-context
     *
     * This is useful for settings options like `channel`, `headless`, `executablePath`, etc.
     */
    launchOptions?: playwright.LaunchOptions;

    /**
     * Context options for the browser context.
     *
     * This is useful for settings options like `viewport`.
     */
    contextOptions?: playwright.BrowserContextOptions;

    /**
     * Chrome DevTools Protocol endpoint to connect to an existing browser instance in case of Chromium family browsers.
     */
    cdpEndpoint?: string;

    /**
     * CDP headers to send with the connect request.
     */
    cdpHeaders?: Record<string, string>;

    /**
     * Timeout in milliseconds for connecting to CDP endpoint. Defaults to 30000 (30 seconds). Pass 0 to disable timeout.
     */
    cdpTimeout?: number;

    /**
     * Remote endpoint to connect to an existing Playwright server. May be a
     * WebSocket URL string, or a [ConnectOptions] object that mirrors the
     * `connectOptions` shape used by the test runner. When passed as an object,
     * `exposeNetwork`, `headers`, `slowMo`, and `timeout` are forwarded to the
     * underlying connect call.
     */
    remoteEndpoint?: string | playwright.ConnectOptions & { endpoint: string };

    /**
     * Paths to TypeScript files to add as initialization scripts for Playwright page.
     */
    initPage?: string[];

    /**
     * Paths to JavaScript files to add as initialization scripts.
     * The scripts will be evaluated in every page before any of the page's scripts.
     */
    initScript?: string[];
  },

  /**
   * Connect to a running browser instance (Edge/Chrome only). If specified, `browser`
   * config is ignored.
   * Requires the "Playwright Extension" to be installed.
   */
  extension?: boolean;

  server?: {
    /**
     * The port to listen on for SSE or MCP transport.
     */
    port?: number;

    /**
     * The host to bind the server to. Default is localhost. Use 0.0.0.0 to bind to all interfaces.
     */
    host?: string;

    /**
     * The hosts this server is allowed to serve from. Defaults to the host server is bound to.
     * This is not for CORS, but rather for the DNS rebinding protection.
     */
    allowedHosts?: string[];
  },

  /**
   * List of enabled tool capabilities. Possible values:
   *   - 'core': Core browser automation features.
   *   - 'pdf': PDF generation and manipulation.
   *   - 'vision': Coordinate-based interactions.
   *   - 'devtools': Developer tools features.
   */
  capabilities?: ToolCapability[];

  /**
   * Whether to save the Playwright session into the output directory.
   */
  saveSession?: boolean;

  /**
   * Reuse the same browser context between all connected HTTP clients.
   */
  sharedBrowserContext?: boolean;

  /**
   * Secrets are used to replace matching plain text in the tool responses to prevent the LLM
   * from accidentally getting sensitive data. It is a convenience and not a security feature,
   * make sure to always examine information coming in and from the tool on the client.
   */
  secrets?: Record<string, string>;

  /**
   * The directory to save output files.
   */
  outputDir?: string;

  /**
   * Threshold for evicting old output files, in bytes.
   */
  outputMaxSize?: number;

  console?: {
    /**
     * The level of console messages to return. Each level includes the messages of more severe levels. Defaults to "info".
     */
    level?: 'error' | 'warning' | 'info' | 'debug';
  },

  network?: {
    /**
     * List of origins to allow the browser to request. Default is to allow all. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
     *
     * Supported formats:
     * - Full origin: `https://example.com:8080` - matches only that origin
     * - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
     */
    allowedOrigins?: string[];

    /**
     * List of origins to block the browser to request. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
     *
     * Supported formats:
     * - Full origin: `https://example.com:8080` - matches only that origin
     * - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
     */
    blockedOrigins?: string[];
  };

  /**
   * Specify the attribute to use for test ids, defaults to "data-testid".
   */
  testIdAttribute?: string;

  timeouts?: {
    /*
     * Configures default action timeout: https://playwright.dev/docs/api/class-page#page-set-default-timeout. Defaults to 5000ms.
     */
    action?: number;

    /*
     * Configures default navigation timeout: https://playwright.dev/docs/api/class-page#page-set-default-navigation-timeout. Defaults to 60000ms.
     */
    navigation?: number;

    /**
     * Configures default expect timeout: https://playwright.dev/docs/test-timeouts#expect-timeout. Defaults to 5000ms.
     */
    expect?: number;
  };

  /**
   * Whether to send image responses to the client. Can be "allow", "omit", or "auto". Defaults to "auto", which sends images if the client can display them.
   */
  imageResponses?: 'allow' | 'omit';

  snapshot?: {
    /**
     * When taking snapshots for responses, specifies the mode to use.
     */
    mode?: 'full' | 'none';
  };

  /**
   * allowUnrestrictedFileAccess acts as a guardrail to prevent the LLM from accidentally
   * wandering outside its intended workspace. It is a convenience defense to catch unintended
   * file access, not a secure boundary; a deliberate attempt to reach other directories can be
   * easily worked around, so always rely on client-level permissions for true security.
   */
  allowUnrestrictedFileAccess?: boolean;

  /**
   * Specify the language to use for code generation.
   */
  codegen?: 'typescript' | 'none';
}

Standalone MCP server

When running headed browser on system w/o display or from worker processes of the IDEs, run the MCP server from environment with the DISPLAY and pass the --port flag to enable HTTP transport.

npx @phishark/playwright-mcp@latest --port 8931

And then in MCP client config, set the url to the HTTP endpoint:

{
  "mcpServers": {
    "playwright": {
      "url": "http://localhost:8931/mcp"
    }
  }
}

Related MCP server: browser-devtools-mcp

Security

Playwright MCP is not a security boundary. See MCP Security Best Practices for guidance on securing your deployment.

NOTE: The Docker implementation only supports headless chromium at the moment.

{
  "mcpServers": {
    "playwright": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "--init", "--pull=always", "mcr.microsoft.com/playwright/mcp"]
    }
  }
}

Or If you prefer to run the container as a long-lived service instead of letting the MCP client spawn it, use:

docker run -d -i --rm --init --pull=always \
  --entrypoint node \
  --name playwright \
  -p 8931:8931 \
  mcr.microsoft.com/playwright/mcp \
  /app/cli.js --headless --browser chromium --no-sandbox --port 8931 --host 0.0.0.0

The server will listen on host port 8931 and can be reached by any MCP client.

You can build the Docker image yourself.

docker build -t mcr.microsoft.com/playwright/mcp .
import http from 'http';

import { createConnection } from '@phishark/playwright-mcp';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';

http.createServer(async (req, res) => {
  // ...

  // Creates a headless Playwright MCP server with SSE transport
  const connection = await createConnection({ browser: { launchOptions: { headless: true } } });
  const transport = new SSEServerTransport('/messages', res);
  await connection.connect(transport);

  // ...
});

Tools

  • browser_click

    • Title: Click

    • Description: Perform click on a web page

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string): Exact target element reference from the page snapshot, or a unique element selector

      • doubleClick (boolean, optional): Whether to perform a double click instead of a single click

      • button (string, optional): Button to click, defaults to left

      • modifiers (array, optional): Modifier keys to press

    • Read-only: false

  • browser_close

    • Title: Close browser

    • Description: Close the page

    • Parameters: None

    • Read-only: false

  • browser_console_messages

    • Title: Get console messages

    • Description: Returns all console messages

    • Parameters:

      • level (string): Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info".

      • all (boolean, optional): Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false.

      • filename (string, optional): Filename to save the console messages to. If not provided, messages are returned as text.

    • Read-only: true

  • browser_drag

    • Title: Drag mouse

    • Description: Perform drag and drop between two elements

    • Parameters:

      • startElement (string, optional): Human-readable source element description used to obtain the permission to interact with the element

      • startTarget (string): Exact target element reference from the page snapshot, or a unique element selector

      • endElement (string, optional): Human-readable target element description used to obtain the permission to interact with the element

      • endTarget (string): Exact target element reference from the page snapshot, or a unique element selector

    • Read-only: false

  • browser_drop

    • Title: Drop files or data onto an element

    • Description: Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided.

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string): Exact target element reference from the page snapshot, or a unique element selector

      • paths (array, optional): Absolute paths to files to drop onto the element.

      • data (object, optional): Data to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}).

    • Read-only: false

  • browser_evaluate

    • Title: Evaluate JavaScript

    • Description: Evaluate JavaScript expression on page or element

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string, optional): Exact target element reference from the page snapshot, or a unique element selector

      • function (string): () => { /* code / } or (element) => { / code */ } when element is provided

      • filename (string, optional): Filename to save the result to. If not provided, result is returned as text.

    • Read-only: false

  • browser_file_upload

    • Title: Upload files

    • Description: Upload one or multiple files

    • Parameters:

      • paths (array, optional): The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled.

    • Read-only: false

  • browser_fill_form

    • Title: Fill form

    • Description: Fill multiple form fields

    • Parameters:

      • fields (array): Fields to fill in

    • Read-only: false

  • browser_find

    • Title: Find in page snapshot

    • Description: Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.

    • Parameters:

      • text (string, optional): Plain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both.

      • regex (string, optional): Regular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both.

    • Read-only: true

  • browser_handle_dialog

    • Title: Handle a dialog

    • Description: Handle a dialog

    • Parameters:

      • accept (boolean): Whether to accept the dialog.

      • promptText (string, optional): The text of the prompt in case of a prompt dialog.

    • Read-only: false

  • browser_hover

    • Title: Hover mouse

    • Description: Hover over element on page

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string): Exact target element reference from the page snapshot, or a unique element selector

    • Read-only: false

  • browser_navigate

    • Title: Navigate to a URL

    • Description: Navigate to a URL

    • Parameters:

      • url (string): The URL to navigate to

    • Read-only: false

  • browser_navigate_back

    • Title: Go back

    • Description: Go back to the previous page in the history

    • Parameters: None

    • Read-only: false

  • browser_network_request

    • Title: Show network request details

    • Description: Returns full details (headers and body) of a single network request, or a single part if part is set. Use the number from browser_network_requests.

    • Parameters:

      • index (integer): 1-based index of the request, as printed by browser_network_requests.

      • part (string, optional): Return only this part of the request. Omit to return full details.

      • filename (string, optional): Filename to save the result to. If not provided, output is returned as text.

    • Read-only: true

  • browser_network_requests

    • Title: List network requests

    • Description: Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.

    • Parameters:

      • static (boolean): Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false.

      • filter (string, optional): Only return requests whose URL matches this regexp (e.g. "/api/.*user").

      • filename (string, optional): Filename to save the network requests to. If not provided, requests are returned as text.

    • Read-only: true

  • browser_press_key

    • Title: Press a key

    • Description: Press a key on the keyboard

    • Parameters:

      • key (string): Name of the key to press or a character to generate, such as ArrowLeft or a

    • Read-only: false

  • browser_resize

    • Title: Resize browser window

    • Description: Resize the browser window

    • Parameters:

      • width (number): Width of the browser window

      • height (number): Height of the browser window

    • Read-only: false

  • browser_run_code_unsafe

    • Title: Run Playwright code (unsafe)

    • Description: Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.

    • Parameters:

      • code (string, optional): A JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction. For example: async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }

      • filename (string, optional): Load code from the specified file. If both code and filename are provided, code will be ignored.

    • Read-only: false

  • browser_select_option

    • Title: Select option

    • Description: Select an option in a dropdown

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string): Exact target element reference from the page snapshot, or a unique element selector

      • values (array): Array of values to select in the dropdown. This can be a single value or multiple values.

    • Read-only: false

  • browser_snapshot

    • Title: Page snapshot

    • Description: Capture accessibility snapshot of the current page, this is better than screenshot

    • Parameters:

      • target (string, optional): Exact target element reference from the page snapshot, or a unique element selector

      • filename (string, optional): Save snapshot to markdown file instead of returning it in the response.

      • depth (number, optional): Limit the depth of the snapshot tree

      • boxes (boolean, optional): Include each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect)

    • Read-only: true

  • browser_take_screenshot

    • Title: Take a screenshot

    • Description: Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string, optional): Exact target element reference from the page snapshot, or a unique element selector

      • type (string): Image format for the screenshot. Default is png.

      • filename (string, optional): File name to save the screenshot to. Defaults to page-{timestamp}.{png|jpeg} if not specified. Prefer relative file names to stay within the output directory.

      • fullPage (boolean, optional): When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots.

      • scale (string): Image resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css.

    • Read-only: true

  • browser_type

    • Title: Type text

    • Description: Type text into editable element

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string): Exact target element reference from the page snapshot, or a unique element selector

      • text (string): Text to type into the element

      • submit (boolean, optional): Whether to submit entered text (press Enter after)

      • slowly (boolean, optional): Whether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once.

    • Read-only: false

  • browser_wait_for

    • Title: Wait for

    • Description: Wait for text to appear or disappear or a specified time to pass

    • Parameters:

      • time (number, optional): The time to wait in seconds

      • text (string, optional): The text to wait for

      • textGone (string, optional): The text to wait for to disappear

    • Read-only: false

  • browser_tabs

    • Title: Manage tabs

    • Description: List, create, close, or select a browser tab.

    • Parameters:

      • action (string): Operation to perform

      • index (number, optional): Tab index, used for close/select. If omitted for close, current tab is closed.

      • url (string, optional): URL to navigate to in the new tab, used for new.

    • Read-only: false

  • browser_get_config

    • Title: Get config

    • Description: Get the final resolved config after merging CLI options, environment variables and config file.

    • Parameters: None

    • Read-only: true

  • browser_network_state_set

    • Title: Set network state

    • Description: Sets the browser network state to online or offline. When offline, all network requests will fail.

    • Parameters:

      • state (string): Set to "offline" to simulate offline mode, "online" to restore network connectivity

    • Read-only: false

  • browser_route

    • Title: Mock network requests

    • Description: Set up a route to mock network requests matching a URL pattern

    • Parameters:

      • pattern (string): URL pattern to match (e.g., "/api/users", "/*.{png,jpg}")

      • status (number, optional): HTTP status code to return (default: 200)

      • body (string, optional): Response body (text or JSON string)

      • contentType (string, optional): Content-Type header (e.g., "application/json", "text/html")

      • headers (array, optional): Headers to add in "Name: Value" format

      • removeHeaders (string, optional): Comma-separated list of header names to remove from request

    • Read-only: false

  • browser_route_list

    • Title: List network routes

    • Description: List all active network routes

    • Parameters: None

    • Read-only: true

  • browser_unroute

    • Title: Remove network routes

    • Description: Remove network routes matching a pattern (or all routes if no pattern specified)

    • Parameters:

      • pattern (string, optional): URL pattern to unroute (omit to remove all routes)

    • Read-only: false

  • browser_cookie_clear

    • Title: Clear cookies

    • Description: Clear all cookies

    • Parameters: None

    • Read-only: false

  • browser_cookie_delete

    • Title: Delete cookie

    • Description: Delete a specific cookie

    • Parameters:

      • name (string): Cookie name to delete

    • Read-only: false

  • browser_cookie_get

    • Title: Get cookie

    • Description: Get a specific cookie by name

    • Parameters:

      • name (string): Cookie name to get

    • Read-only: true

  • browser_cookie_list

    • Title: List cookies

    • Description: List all cookies (optionally filtered by domain/path)

    • Parameters:

      • domain (string, optional): Filter cookies by domain

      • path (string, optional): Filter cookies by path

    • Read-only: true

  • browser_cookie_set

    • Title: Set cookie

    • Description: Set a cookie with optional flags (domain, path, expires, httpOnly, secure, sameSite)

    • Parameters:

      • name (string): Cookie name

      • value (string): Cookie value

      • domain (string, optional): Cookie domain

      • path (string, optional): Cookie path

      • expires (number, optional): Cookie expiration as Unix timestamp

      • httpOnly (boolean, optional): Whether the cookie is HTTP only

      • secure (boolean, optional): Whether the cookie is secure

      • sameSite (string, optional): Cookie SameSite attribute

    • Read-only: false

  • browser_localstorage_clear

    • Title: Clear localStorage

    • Description: Clear all localStorage

    • Parameters: None

    • Read-only: false

  • browser_localstorage_delete

    • Title: Delete localStorage item

    • Description: Delete a localStorage item

    • Parameters:

      • key (string): Key to delete

    • Read-only: false

  • browser_localstorage_get

    • Title: Get localStorage item

    • Description: Get a localStorage item by key

    • Parameters:

      • key (string): Key to get

    • Read-only: true

  • browser_localstorage_list

    • Title: List localStorage

    • Description: List all localStorage key-value pairs

    • Parameters: None

    • Read-only: true

  • browser_localstorage_set

    • Title: Set localStorage item

    • Description: Set a localStorage item

    • Parameters:

      • key (string): Key to set

      • value (string): Value to set

    • Read-only: false

  • browser_sessionstorage_clear

    • Title: Clear sessionStorage

    • Description: Clear all sessionStorage

    • Parameters: None

    • Read-only: false

  • browser_sessionstorage_delete

    • Title: Delete sessionStorage item

    • Description: Delete a sessionStorage item

    • Parameters:

      • key (string): Key to delete

    • Read-only: false

  • browser_sessionstorage_get

    • Title: Get sessionStorage item

    • Description: Get a sessionStorage item by key

    • Parameters:

      • key (string): Key to get

    • Read-only: true

  • browser_sessionstorage_list

    • Title: List sessionStorage

    • Description: List all sessionStorage key-value pairs

    • Parameters: None

    • Read-only: true

  • browser_sessionstorage_set

    • Title: Set sessionStorage item

    • Description: Set a sessionStorage item

    • Parameters:

      • key (string): Key to set

      • value (string): Value to set

    • Read-only: false

  • browser_set_storage_state

    • Title: Restore storage state

    • Description: Restore storage state (cookies, local storage) from a file. This clears existing cookies and local storage before restoring.

    • Parameters:

      • filename (string): Path to the storage state file to restore from

    • Read-only: false

  • browser_storage_state

    • Title: Save storage state

    • Description: Save storage state (cookies, local storage) to a file for later reuse

    • Parameters:

      • filename (string, optional): File name to save the storage state to. Defaults to storage-state-{timestamp}.json if not specified.

    • Read-only: true

  • browser_annotate

    • Title: Annotate the current page

    • Description: Open the Playwright Dashboard in annotation mode for the current page and wait for the user to draw annotations. Returns the annotated screenshot, ARIA snapshot, and the list of annotations.

    • Parameters: None

    • Read-only: true

  • browser_hide_highlight

    • Title: Hide element highlight

    • Description: Remove a highlight overlay previously added for the element.

    • Parameters:

      • element (string, optional): Human-readable element description used when adding the highlight; must match the value passed to browser_highlight.

      • target (string, optional): Exact target element reference from the page snapshot, or a unique element selector

    • Read-only: true

  • browser_highlight

    • Title: Highlight element

    • Description: Show a persistent highlight overlay around the element on the page.

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string): Exact target element reference from the page snapshot, or a unique element selector

      • style (string, optional): Additional inline CSS applied to the highlight overlay, e.g. "outline: 2px dashed red".

    • Read-only: true

  • browser_resume

    • Title: Resume paused script execution

    • Description: Resume script execution after it was paused. When called with step set to true, execution will pause again before the next action.

    • Parameters:

      • step (boolean, optional): When true, execution will pause again before the next action, allowing step-by-step debugging.

      • location (string, optional): Pause execution at a specific :, e.g. "example.spec.ts:42".

    • Read-only: false

  • browser_start_tracing

    • Title: Start tracing

    • Description: Start trace recording

    • Parameters: None

    • Read-only: true

  • browser_start_video

    • Title: Start video

    • Description: Start video recording

    • Parameters:

      • filename (string, optional): Filename to save the video.

      • size (object, optional): Video size

    • Read-only: true

  • browser_stop_tracing

    • Title: Stop tracing

    • Description: Stop trace recording

    • Parameters: None

    • Read-only: true

  • browser_stop_video

    • Title: Stop video

    • Description: Stop video recording

    • Parameters: None

    • Read-only: true

  • browser_video_chapter

    • Title: Video chapter

    • Description: Add a chapter marker to the video recording. Shows a full-screen chapter card with blurred backdrop.

    • Parameters:

      • title (string): Chapter title

      • description (string, optional): Chapter description

      • duration (number, optional): Duration in milliseconds to show the chapter card

    • Read-only: true

  • browser_video_hide_actions

    • Title: Hide action overlays

    • Description: Stop annotating actions performed on the page.

    • Parameters: None

    • Read-only: true

  • browser_video_show_actions

    • Title: Show action overlays

    • Description: Annotate subsequent actions performed on the page with a callout that names the action and highlights the target element. Useful while video recording or screencasting.

    • Parameters:

      • duration (number, optional): How long each action annotation stays on screen, in milliseconds. Defaults to 500.

      • position (string, optional): Where to place the action title relative to the page. Defaults to top-right.

      • cursor (string, optional): Cursor decoration for pointer actions. "pointer" (default) animates a mouse pointer from the previous action point to the next one; "none" disables the cursor decoration.

    • Read-only: true

  • browser_mouse_click_xy

    • Title: Click

    • Description: Click mouse button at a given position

    • Parameters:

      • x (number): X coordinate

      • y (number): Y coordinate

      • button (string, optional): Button to click, defaults to left

      • clickCount (number, optional): Number of clicks, defaults to 1

      • delay (number, optional): Time to wait between mouse down and mouse up in milliseconds, defaults to 0

    • Read-only: false

  • browser_mouse_down

    • Title: Press mouse down

    • Description: Press mouse down

    • Parameters:

      • button (string, optional): Button to press, defaults to left

    • Read-only: false

  • browser_mouse_drag_xy

    • Title: Drag mouse

    • Description: Drag left mouse button to a given position

    • Parameters:

      • startX (number): Start X coordinate

      • startY (number): Start Y coordinate

      • endX (number): End X coordinate

      • endY (number): End Y coordinate

    • Read-only: false

  • browser_mouse_move_xy

    • Title: Move mouse

    • Description: Move mouse to a given position

    • Parameters:

      • x (number): X coordinate

      • y (number): Y coordinate

    • Read-only: false

  • browser_mouse_up

    • Title: Press mouse up

    • Description: Press mouse up

    • Parameters:

      • button (string, optional): Button to press, defaults to left

    • Read-only: false

  • browser_mouse_wheel

    • Title: Scroll mouse wheel

    • Description: Scroll mouse wheel

    • Parameters:

      • deltaX (number): X delta

      • deltaY (number): Y delta

    • Read-only: false

  • browser_pdf_save

    • Title: Save as PDF

    • Description: Save page as PDF

    • Parameters:

      • filename (string, optional): File name to save the pdf to. Defaults to page-{timestamp}.pdf if not specified. Prefer relative file names to stay within the output directory.

    • Read-only: true

  • browser_generate_locator

    • Title: Create locator for element

    • Description: Generate locator for the given element to use in tests

    • Parameters:

      • element (string, optional): Human-readable element description used to obtain permission to interact with the element

      • target (string): Exact target element reference from the page snapshot, or a unique element selector

    • Read-only: true

  • browser_verify_element_visible

    • Title: Verify element visible

    • Description: Verify element is visible on the page

    • Parameters:

      • role (string): ROLE of the element. Can be found in the snapshot like this: - {ROLE} "Accessible Name":

      • accessibleName (string): ACCESSIBLE_NAME of the element. Can be found in the snapshot like this: - role "{ACCESSIBLE_NAME}"

    • Read-only: false

  • browser_verify_list_visible

    • Title: Verify list visible

    • Description: Verify list is visible on the page

    • Parameters:

      • element (string): Human-readable list description

      • target (string): Exact target element reference that points to the list

      • items (array): Items to verify

    • Read-only: false

  • browser_verify_text_visible

    • Title: Verify text visible

    • Description: Verify text is visible on the page. Prefer browser_verify_element_visible if possible.

    • Parameters:

      • text (string): TEXT to verify. Can be found in the snapshot like this: - role "Accessible Name": {TEXT} or like this: - text: {TEXT}

    • Read-only: false

  • browser_verify_value

    • Title: Verify value

    • Description: Verify element value

    • Parameters:

      • type (string): Type of the element

      • element (string): Human-readable element description

      • target (string): Exact target element reference from the page snapshot

      • value (string): Value to verify. For checkbox, use "true" or "false".

    • Read-only: false

Available Tools

26 tools
browser_clickC
Destructive

Perform click on a web page

ParametersJSON Schema
NameRequiredDescriptionDefault
buttonNoButton to click, defaults to left
targetYesExact target element reference from the page snapshot, or a unique element selector
elementNoHuman-readable element description used to obtain permission to interact with the element
modifiersNoModifier keys to press
doubleClickNoWhether to perform a double click instead of a single click

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds no behavioral context beyond stating the action. No discussion of side effects, permissions, or result handling.

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 at five words, providing the core action efficiently. While it lacks detail, it is front-loaded and to the point.

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 5 parameters and no output schema, the description is insufficient. It does not explain return values, error behavior, or the effect of parameters like doubleClick or modifiers. The annotations partially cover safety, but behavioral gaps remain.

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?

The input schema covers all five parameters with descriptions, achieving 100% coverage. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the verb 'click' and the resource 'a web page', providing a basic understanding. However, it does not distinguish this tool from sibling tools like browser_hover or browser_drop, which are also interactions on the page.

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. The description does not mention prerequisites, typical scenarios, or when not to use browser_click.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_closeB
Destructive

Close the page

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

The description only repeats the action 'close', which is already implied by the tool name and annotations (destructiveHint=true). Annotations already convey destructive behavior, and the description adds no extra context about what gets destroyed, whether unsaved data is affected, or if confirmation dialogs appear. No contradictions with annotations.

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 only three words, perfectly concise and front-loaded. Every word is necessary; there is no waste.

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

Completeness3/5

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

Given the tool has no parameters, no output schema, and annotations cover the destructive hint, the description is minimally adequate. However, it does not specify what 'the page' refers to (e.g., current tab? popup?), and whether any side effects occur. For a simple atomic action, this may suffice, but more context would reduce ambiguity.

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

Parameters4/5

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

The tool has zero parameters and schema coverage is 100%. Per the guidelines, 0 parameters gives a baseline of 4. The description does not need to add parameter details since none exist.

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

Purpose4/5

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

The description 'Close the page' clearly states the action and resource (close + page). It is specific enough to distinguish from sibling tools like browser_navigate or browser_click, which have different purposes. However, it lacks details about what exactly is closed (current tab vs entire browser), leaving minor ambiguity.

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 (e.g., browser_navigate_back or browser_tabs to switch contexts). There is no mention of prerequisites, side effects, or situations where closing is inappropriate. The agent must infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_console_messagesB
Read-only

Returns all console messages

ParametersJSON Schema
NameRequiredDescriptionDefault
allNoReturn all console messages since the beginning of the session, not just since the last navigation. Defaults to false.
levelYesLevel of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info".info
filenameNoFilename to save the console messages to. If not provided, messages are returned as text.

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. The description adds no further behavioral details beyond 'returns console messages', which is adequate but does not disclose nuances like level hierarchy or session 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 one sentence of four words, which is very concise. It is front-loaded and contains no unnecessary text, though it could be more informative without sacrificing brevity.

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 three parameters including a hierarchical level and an 'all' flag, the description fails to explain these behaviors. The file saving parameter is also unmentioned. The description is too sparse for the tool's moderate complexity.

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%, so the parameters are fully documented in the schema. The description adds no extra meaning beyond what is in the schema, so baseline 3 is appropriate.

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

Purpose4/5

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

The description states 'Returns all console messages' which clearly indicates the verb (returns) and resource (console messages). However, it does not distinguish itself from sibling tools like browser_network_requests or browser_network_request that also retrieve logs, so it lacks sibling differentiation.

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. There is no mention of context, prerequisites, or situations where it should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_dragB
Destructive

Perform drag and drop between two elements

ParametersJSON Schema
NameRequiredDescriptionDefault
endTargetYesExact target element reference from the page snapshot, or a unique element selector
endElementNoHuman-readable target element description used to obtain the permission to interact with the element
startTargetYesExact target element reference from the page snapshot, or a unique element selector
startElementNoHuman-readable source element description used to obtain the permission to interact with the element

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, indicating mutation. The description adds no new behavioral insight beyond confirming that a drag-and-drop action is performed. It does not contradict annotations.

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 a single sentence, front-loaded with the purpose. It is concise and efficient, though it could benefit from slightly more detail without being verbose.

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 complexity of drag-and-drop interactions (coordinate offsets, events triggered, prerequisites) and the lack of an output schema, the description is too minimal. It does not explain what happens after the action (e.g., success/failure feedback) or any side effects.

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 coverage is 100% with all parameters described. The description adds no additional semantic value beyond what the schema already provides, such as clarifying the relationship between startTarget/endTarget and the drag-and-drop action. Baseline score of 3 is appropriate.

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

Purpose4/5

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

The description states 'Perform drag and drop between two elements,' which is a clear and specific verb-resource combination. It distinguishes the tool from siblings like browser_click and browser_hover, but there is a sibling named browser_drop which could be confused; the description does not differentiate between drag-and-drop and drop-only actions.

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 such as browser_drop or browser_click. There is no mention of prerequisites (e.g., elements must be draggable) or exclusions, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_dropA
Destructive

Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataNoData to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}).
pathsNoAbsolute paths to files to drop onto the element.
targetYesExact target element reference from the page snapshot, or a unique element selector
elementNoHuman-readable element description used to obtain permission to interact with the element

TDQS

A4/5.0
Behavior3/5

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

Annotations indicate destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds context about drag origin and data requirements but does not detail side effects, success/failure behavior, or permission needs beyond the schema. Adds some value beyond annotations.

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?

Two sentences, front-loaded with purpose and constraint. No wasted words, clear and efficient.

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?

For a tool with no output schema, the description provides enough context for selection and use. It explains what the tool does and key constraints. Could be improved by mentioning return behavior but is adequate for a drop action.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying the condition 'at least one of paths or data must be provided', which is not enforced by the schema (only target is required). This helps the agent understand parameter interaction.

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 the action (drop), what can be dropped (files or MIME-typed data), and the condition (at least one of paths or data). It distinguishes from sibling tools like browser_drag (in-page) and browser_file_upload (file input).

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

Usage Guidelines3/5

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

The description includes a condition (at least one of paths or data) but does not explicitly state when to use this tool versus alternatives like browser_drag or browser_file_upload. Some implicit guidance but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_evaluateC
Destructive

Evaluate JavaScript expression on page or element

ParametersJSON Schema
NameRequiredDescriptionDefault
targetNoExact target element reference from the page snapshot, or a unique element selector
elementNoHuman-readable element description used to obtain permission to interact with the element
filenameNoFilename to save the result to. If not provided, result is returned as text.
functionYes() => { /* code */ } or (element) => { /* code */ } when element is provided

TDQS

C2.9/5.0
Behavior2/5

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

The description does not provide additional behavioral context beyond what annotations already convey. It does not warn about destructive nature or open world implications.

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 concise at one sentence but lacks any structural elements (e.g., bullet points, examples) that would improve usability.

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 that executes arbitrary code, the description is overly minimal. It lacks guidance on security, return format, or typical use cases.

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 covers all parameters with descriptions. The tool description does not add additional parameter semantics beyond the schema.

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

Purpose4/5

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

The description clearly states the verb 'Evaluate' and resource 'JavaScript expression on page or element'. However, it does not differentiate from the sibling tool 'browser_run_code_unsafe', which likely has similar functionality.

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 like browser_run_code_unsafe or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_file_uploadC
Destructive

Upload one or multiple files

ParametersJSON Schema
NameRequiredDescriptionDefault
pathsNoThe absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled.

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that omitting paths cancels the file chooser, which is useful but minimal. It does not disclose what happens with invalid paths or other side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one sentence), which is concise but at the expense of completeness. It is front-loaded but lacks important context about the file upload mechanism.

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 no output schema and the tool's interaction with file dialogs, the description is incomplete. It does not explain that the browser must have an active file input, nor what constitutes a successful upload, which is critical for 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?

Input schema has 100% coverage on the 'paths' parameter with a detailed description. The tool description merely repeats 'upload one or multiple files', adding no new semantic information beyond the schema.

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

Purpose4/5

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

The description clearly states the verb 'upload' and the resource 'files', and implies it can handle multiple files. However, it does not differentiate from sibling tools like 'browser_drop' which might also handle file input, lacking explicit distinction.

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 on when to use this tool vs alternatives (e.g., browser_drop). The only behavioral note is about cancellation when paths are omitted, but no context on prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_fill_formC
Destructive

Fill multiple form fields

ParametersJSON Schema
NameRequiredDescriptionDefault
fieldsYesFields to fill in

TDQS

C2.9/5.0
Behavior2/5

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

The description adds no behavioral context beyond the annotations. Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description does not explain that filling fields may permanently change the page state. No mention of how different field types are handled (though the schema partially covers this).

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?

At just four words, the description is extremely concise and to the point. No fluff or redundancy. However, it could be slightly more informative without losing conciseness.

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?

The description is too minimal for a tool that modifies a page. It lacks context about prerequisites (e.g., requiring a page snapshot), the relation to sibling tools like browser_click or browser_type, and what 'fill' entails for various control types beyond what the schema already says. The destructive hint is present but not elaborated.

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% for the 'fields' parameter, detailing each subfield. The tool description adds no extra meaning beyond the parameter name and the fact it fills multiple fields. Baseline 3 is appropriate since the schema does the heavy lifting.

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

Purpose4/5

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

The description 'Fill multiple form fields' clearly states the action (fill) and the resource (form fields), and the word 'multiple' distinguishes it from single-field tools like browser_type. However, it does not explicitly differentiate from browser_select_option for combobox fields.

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 on when to use this tool versus alternatives (e.g., browser_type for single fields, browser_select_option for dropdowns). No mention of prerequisites like having a page snapshot or that the form fields must exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_findA
Read-only

Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.

ParametersJSON Schema
NameRequiredDescriptionDefault
textNoPlain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both.
regexNoRegular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both.

TDQS

A4.3/5.0
Behavior4/5

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

Describes search behavior (case-insensitive substring for text, case-sensitive regex with flags), and output format (matches with surrounding context under path). Annotations already indicate read-only and non-destructive, and description reinforces these without contradiction.

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?

Relatively concise single sentence that front-loads the action. Some redundancy could be trimmed, but overall well-structured.

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?

Explains return format sufficiently given no output schema. All key behavioral aspects are covered. Annotations handle safety. Minor gap: no explanation of 'accessibility snapshot' or 'ref'.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds clarifying details about case sensitivity and regex flag syntax, enhancing understanding beyond the schema.

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?

Clearly states it searches the accessibility snapshot for text or regex, returning matching nodes with context. Uses specific verb and resource, and distinguishes itself from full snapshot capture by noting cost savings.

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

Usage Guidelines4/5

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

Explicitly advises use when only needing to locate an element and its ref, being cheaper than full snapshot. Does not explicitly mention when not to use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_handle_dialogC
Destructive

Handle a dialog

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

TDQS

C2.2/5.0
Behavior2/5

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

The description adds no details beyond annotations. Annotations indicate destructiveHint=true and readOnlyHint=false, but the description does not clarify that accepting a dialog may submit a form or proceed with an action, or that dismissing (accept: false) cancels it. No behavioral context for promptText usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise (4 words) but under-specified. The description fails to include essential information that would fit in one or two sentences, making it incomplete rather than efficiently concise.

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 low complexity (2 params, no output schema), the description should at least state that it handles browser modal dialogs (alert, confirm, prompt) and that promptText is only required for prompt dialogs. It lacks these contextual details, leaving the agent without clear usage guidance.

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%, so the schema already explains both parameters (accept and promptText). The description adds no additional meaning, aligning with the baseline score of 3 for high coverage.

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 a tautology of the tool name and resource. It lacks specificity about what handling entails (accepting, dismissing) and does not distinguish from sibling tools like browser_click or browser_fill_form.

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 (e.g., waiting for a dialog, using browser_evaluate to check for dialogs). There are no exclusions or contextual hints about prerequisites like dialog existence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_hoverC
Destructive

Hover over element on page

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYesExact target element reference from the page snapshot, or a unique element selector
elementNoHuman-readable element description used to obtain permission to interact with the element

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already indicate destructiveHint=true (state-changing) and readOnlyHint=false, but the description adds no behavioral context, such as what side effects hovering may trigger (e.g., popups, style changes).

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 a single, efficient sentence with no extraneous words. It conveys the core action without waste, though it could benefit from more detail without sacrificing conciseness.

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 there is no output schema and the description is minimal, the agent lacks information about return behavior (e.g., success/failure states) and sequencing relative to other browser actions. The description is insufficient for a tool with two parameters and destructive potential.

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 coverage is 100% with both parameters fully described. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

Purpose4/5

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

The description 'Hover over element on page' clearly states the action (hover) and the target (element on page), distinguishing it from sibling tools like browser_click and browser_drag. However, it lacks specificity about the effect (e.g., no mention of triggering hover events).

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 vs alternatives, no prerequisites, and no exclusions. This forces the agent to infer usage from context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_navigateC
Destructive

Navigate to a URL

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to navigate to

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already set `destructiveHint: true`, indicating state change. The description adds no behavioral details beyond what annotations provide, such as whether navigation waits for page load or handles errors. No contradiction with annotations.

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 at 4 words. While efficient, it could benefit from slightly more detail without becoming verbose. Front-loading is good, but it borders on being too brief.

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 low complexity, the description lacks important context such as whether navigation occurs in the same tab, any prerequisites (e.g., page loaded), or error handling. It is insufficient for a tool with multiple sibling tools.

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 coverage is 100% with a description for the single `url` parameter. The tool description does not add additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

Purpose4/5

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

The description 'Navigate to a URL' clearly conveys a specific verb and resource. While it is concise, it effectively distinguishes from sibling tools like `browser_navigate_back` through the absence of 'Back'. However, it could be more explicit about opening or replacing the current page.

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 usage guidelines are provided. The description does not indicate when to use this tool over alternatives like clicking a link or using `browser_navigate_back`. It lacks context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_navigate_backA
Destructive

Go back to the previous page in the history

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

Annotations already provide destructiveHint=true, but the description adds no behavioral context beyond restating the action. Does not disclose state changes, history constraints, or post-conditions.

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?

Single sentence, front-loaded with action, no unnecessary words. Highly concise.

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?

For a simple zero-param action with annotations, the description is nearly complete. Could mention that history must exist, but overall sufficient.

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

Parameters4/5

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

No parameters exist, so schema coverage is 100%. Description correctly omits parameter details, earning baseline 4 for zero-param tools.

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?

Description clearly states the verb 'Go back' and the resource 'previous page in the history', distinguishing it from siblings like browser_navigate (go to URL) and browser_close (close tab).

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 explicit guidance on when to use this tool vs alternatives, no exclusions or prerequisites mentioned. Usage is implied but not clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_network_requestA
Read-only

Returns full details (headers and body) of a single network request, or a single part if part is set. Use the number from browser_network_requests.

ParametersJSON Schema
NameRequiredDescriptionDefault
partNoReturn only this part of the request. Omit to return full details.
indexYes1-based index of the request, as printed by browser_network_requests.
filenameNoFilename to save the result to. If not provided, output is returned as text.

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Description adds that it returns details but doesn't elaborate on behavior beyond that. No contradiction.

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?

Two concise sentences, front-loaded with purpose. Every word earns its place; no fluff.

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?

For a simple retrieval tool with 3 parameters and no output schema, the description covers the main functionality and the prerequisite. Minor gap: doesn't describe what happens if 'part' is omitted vs set, but schema covers that.

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

Parameters4/5

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

Schema coverage is 100%, but description adds value by linking the `index` parameter to `browser_network_requests`, clarifying its origin. This goes beyond what the schema 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?

Description clearly states it returns full details (headers and body) of a single network request, or a specific part via the `part` parameter. It distinguishes from sibling `browser_network_requests` by focusing on a single request's details.

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

Usage Guidelines4/5

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

Explicitly instructs to use the number from `browser_network_requests`, indicating a prerequisite step. No explicit when-not-to-use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_network_requestsA
Read-only

Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNoOnly return requests whose URL matches this regexp (e.g. "/api/.*user").
staticYesWhether to include successful static resources like images, fonts, scripts, etc. Defaults to false.
filenameNoFilename to save the network requests to. If not provided, requests are returned as text.

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by noting the scope 'since loading the page'. No additional behavioral details like pagination or rate limits are needed for this simple read 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?

Two sentences with no wasted words. The purpose and usage are front-loaded, making it easy to scan.

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?

The description adequately explains the tool's output (numbered list) and usage. Given the simple nature of the tool and good schema/annotations, it is nearly complete; a minor addition could be what the list entries contain (e.g., URLs).

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 each parameter having a clear description. The tool description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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 the specific verb 'Returns' and resource 'numbered list of network requests since loading the page', which clearly distinguishes it from the sibling 'browser_network_request' that gets full details for a specific request.

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

Usage Guidelines4/5

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

The description explicitly directs to use 'browser_network_request' with the number for full details, providing a clear alternative. It does not state when not to use, but the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_press_keyA
Destructive

Press a key on the keyboard

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYesName of the key to press or a character to generate, such as `ArrowLeft` or `a`

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so agent knows it modifies state. Description adds context that it presses a single key, not a sequence, but does not elaborate on behavior like modifier keys or page focus.

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?

Single sentence, no unnecessary words. Highly concise and front-loaded.

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?

For a simple tool with one parameter, no output schema, and annotations covering destructive nature, the description is mostly adequate. Could mention typical use cases or that page must be focused, but overall sufficient.

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 provides 100% coverage with clear description for the 'key' parameter. Description adds no additional meaning beyond what the schema already offers.

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?

Description states exact action: 'Press a key on the keyboard'. Clearly distinguishes from siblings like browser_type (which types text) and browser_click (which clicks).

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 on when to use this tool versus alternatives like browser_type for typing sequences or browser_click for clicks. No mention of prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_resizeB
Destructive

Resize the browser window

ParametersJSON Schema
NameRequiredDescriptionDefault
widthYesWidth of the browser window
heightYesHeight of the browser window

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds no additional behavioral context (e.g., effect on viewport, error handling). No contradiction.

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?

Single sentence, no fluff. Could benefit from a brief note on units or constraints, but appropriately concise for a simple operation.

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

Completeness3/5

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

Simple tool with full schema coverage and no output schema. Lacks usage context (e.g., valid ranges, impact on page state). Adequate but not complete.

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 provides full coverage (100%) with descriptions for width and height. Description adds no extra meaning beyond the schema.

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?

Description clearly states verb 'Resize' and resource 'browser window'. It is specific and distinct from sibling tools like browser_navigate or browser_click.

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 on when to use this tool versus alternatives. No mention of prerequisites, when not to use, or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_run_code_unsafeA
Destructive

Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeNoA JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction. For example: `async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }`
filenameNoLoad code from the specified file. If both code and filename are provided, code will be ignored.

TDQS

A3.5/5.0
Behavior4/5

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

Discloses that it executes arbitrary JavaScript in the Playwright server process, which is beyond the destructiveHint annotation. Clearly indicates the severity (RCE-equivalent).

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?

Two sentences, front-loaded with purpose, followed by a critical safety warning. No redundant information.

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

Completeness3/5

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

Covers essential purpose and safety, but lacks mention of return value or execution context details (e.g., that the page object is passed as argument). Adequate but could be more complete.

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 coverage is 100% with parameter descriptions already present. The tool description does not add additional semantic meaning to the parameters beyond what the schema provides.

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

Purpose4/5

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

Clearly states 'Run a Playwright code snippet' and emphasizes it is unsafe and RCE-equivalent. However, does not explicitly differentiate from sibling tool `browser_evaluate`, which may have overlapping functionality.

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 explicit guidance on when to use this tool versus alternatives. The description only warns of danger, but does not say when it is appropriate or what prerequisites exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_select_optionC
Destructive

Select an option in a dropdown

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYesExact target element reference from the page snapshot, or a unique element selector
valuesYesArray of values to select in the dropdown. This can be a single value or multiple values.
elementNoHuman-readable element description used to obtain permission to interact with the element

TDQS

C2.9/5.0
Behavior2/5

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

The description does not disclose any behavioral traits beyond what annotations already indicate (destructiveHint=true). It adds no value regarding side effects or permissions.

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 a single clear sentence, concise and front-loaded. No wasted words.

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 simple tool, the description is too sparse. It omits important context like behavior when the option is missing, or handling of multiple values. No output schema exists to compensate.

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 coverage is 100%, so the description does not need to explain parameters in depth. However, it adds no additional meaning beyond the schema, e.g., clarifying valid values or multi-select behavior.

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

Purpose4/5

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

The description clearly states the tool selects an option in a dropdown. It is specific and distinct from sibling browser tools like click or type.

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, such as browser_click or browser_type. The description lacks context for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_snapshotA
Read-only

Capture accessibility snapshot of the current page, this is better than screenshot

ParametersJSON Schema
NameRequiredDescriptionDefault
boxesNoInclude each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect)
depthNoLimit the depth of the snapshot tree
targetNoExact target element reference from the page snapshot, or a unique element selector
filenameNoSave snapshot to markdown file instead of returning it in the response.

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and destructiveHint, so the description adds value by describing the output as an 'accessibility snapshot', implying a structural tree rather than a visual image. No contradictions.

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?

Single, front-loaded sentence that is efficient and to the point. However, could include a bit more context without becoming verbose.

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?

No output schema exists, so the description should elaborate on what the snapshot contains (e.g., tree structure, text, properties). The current description omits this, leaving the agent uncertain about return value.

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 coverage is 100% with well-described parameters. The description does not add further parameter detail, but also does not repeat or contradict, meeting the baseline expectation.

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?

Description clearly states the tool captures an 'accessibility snapshot' of the current page, specifying the verb 'capture' and resource. It also contrasts with sibling 'browser_take_screenshot' by claiming it's 'better', providing differentiation.

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

Usage Guidelines4/5

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

Explicitly contrasts with 'browser_take_screenshot' by claiming superiority, implying preference for accessibility info. However, no explicit when-not-to-use or alternative guidance for other scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_tabsB
Destructive

List, create, close, or select a browser tab.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoURL to navigate to in the new tab, used for new.
indexNoTab index, used for close/select. If omitted for close, current tab is closed.
actionYesOperation to perform

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already indicate destructive behavior. The description adds the list of actions but lacks details like what happens on 'list' (returns an array of tabs) or that 'close' defaults to current tab. Some value beyond annotations, but minimal.

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?

Single sentence, front-loaded with actions. Efficient but could be slightly more structured in explaining how actions map to the 'action' parameter.

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 no output schema, the description should mention what 'list' returns. Also missing context on defaults or behavior when parameters are omitted. Incomplete for a multi-action tool.

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 coverage is 100%, so baseline 3. The description does not add any meaning beyond what the schema already provides for the parameters.

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 lists the four actions (list, create, close, select) on browser tabs, distinguishing it from sibling tools like browser_navigate or browser_close which deal with navigation or closing the entire browser.

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. For example, it doesn't explain when to use 'new' vs browser_navigate or 'close' vs browser_close.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_take_screenshotA
Read-only

Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesImage format for the screenshot. Default is png.png
scaleYesImage resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css.css
targetNoExact target element reference from the page snapshot, or a unique element selector
elementNoHuman-readable element description used to obtain permission to interact with the element
filenameNoFile name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg}` if not specified. Prefer relative file names to stay within the output directory.
fullPageNoWhen true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots.

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds limited new behavioral context. It mentions the scope ('current page') and the limitation for actions, but does not describe output format or other behaviors.

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?

Two concise sentences, front-loaded with the essential purpose, no wasted words.

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 the full schema descriptions and the absence of an output schema, the description is adequate for selection and basic understanding. It could improve by noting the return format, but is still complete enough.

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?

Input schema has 100% coverage with descriptions for all 6 parameters, so the description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.

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 takes a screenshot of the current page, and distinguishes from the sibling tool browser_snapshot by noting that this tool cannot be used for actions, while browser_snapshot should be used for that purpose.

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 tells the agent when not to use this tool (for actions) and directs to the alternative browser_snapshot, providing clear usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_typeB
Destructive

Type text into editable element

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText to type into the element
slowlyNoWhether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once.
submitNoWhether to submit entered text (press Enter after)
targetYesExact target element reference from the page snapshot, or a unique element selector
elementNoHuman-readable element description used to obtain permission to interact with the element

TDQS

B3.2/5.0
Behavior2/5

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

Annotations provide destructiveHint and openWorldHint, but the description adds no extra behavioral context. It does not disclose that typing modifies the page, may trigger key handlers, or requires permission for the element. The description merely states the obvious action.

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?

Single sentence, no fluff. Front-loaded with verb and resource. Every word earns its place.

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 5 parameters, no output schema, and destructiveHint, the description is too minimal. It does not explain return behavior, side effects, or permission requirements. Lacks completeness for an agent to use correctly without relying solely on schema.

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 coverage is 100%, so the schema already describes all five parameters. The description does not add meaning beyond what the schema provides. Baseline 3 is appropriate.

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?

Description clearly states the verb 'Type' and the resource 'text into editable element'. It is specific and distinct from sibling tools like browser_click or browser_fill_form, which handle different interactions.

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 on when to use this tool versus alternatives. For instance, it does not differentiate from browser_fill_form or browser_press_key. No mention of prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_wait_forA
Read-only

Wait for text to appear or disappear or a specified time to pass

ParametersJSON Schema
NameRequiredDescriptionDefault
textNoThe text to wait for
timeNoThe time to wait in seconds
textGoneNoThe text to wait for to disappear

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. However, it adds no further behavioral traits beyond the basic wait conditions. The description does not contradict annotations.

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 a single sentence of 12 words, front-loading the key idea. No extra words or fluff. Every word earns its place.

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?

Despite simplicity, the description lacks details on behavior when multiple parameters are provided, what happens if no parameters are given, or the return value. No output schema exists, so these gaps reduce completeness for a tool with no required parameters.

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 coverage is 100% with each parameter described. The description summarizes the three conditions (appear, disappear, time) but does not add deeper semantics like mutual exclusivity or timeout behavior. It adds marginal value beyond the schema.

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 the tool waits for text to appear or disappear or a specified time to pass. It uses a specific verb ('wait') and identifies the resources (text, time). This distinguishes it from sibling tools that perform actions like clicking or navigation.

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

Usage Guidelines3/5

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

The description implies when to use (waiting for text or time) but does not provide explicit guidance on when not to use or alternatives. It lacks exclusionary language or comparisons to sibling tools, so the usage context is only partially clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

phishark_rescanA
Destructive

Capture the current Playwright page evidence and force a fresh PhiShark browser-deep scan.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior2/5

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

Annotations already indicate destructiveHint=true and openWorldHint=true. The description adds 'capture evidence' and 'force a fresh scan' but does not explain what evidence is captured, what side effects occur (e.g., overwriting previous results), or any authorization or rate-limit details. Minimal value beyond annotations.

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?

A single 14-word sentence that front-loads the key verbs ('Capture', 'force') and includes the essential information. No wasted words.

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 the tool has no parameters, no output schema, and annotations cover safety hints, the description is sufficient for an agent to understand the basic action. However, it could clarify the 'evidence' capture process or the scan result format to improve completeness.

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

Parameters4/5

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

The input schema has zero parameters, and schema description coverage is 100% (vacuous). Baseline for 0 parameters is 4; the description does not need to add parameter info, and it correctly omits any.

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 the tool's action ('capture evidence', 'force a fresh scan') and the resources involved ('current Playwright page evidence', 'PhiShark browser-deep scan'). It distinguishes itself from sibling tools like phishark_security_status by indicating that it triggers a new scan rather than querying status.

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

Usage Guidelines3/5

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

The description implies usage when a fresh scan is needed, but it lacks explicit guidance on when to use this tool versus alternatives (e.g., phishark_security_status). No exclusion criteria or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

phishark_security_statusA
Read-only

Show the current page preflight, browser-deep, risk, cache, and policy status.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the specific status categories but does not disclose additional behavioral traits like authentication needs or rate limits.

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 a single, direct sentence with no redundant or wasted words. It is front-loaded and efficiently communicates the tool's purpose.

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?

For a simple read-only status tool with no parameters and no output schema, the description covers the main functionality. However, it lacks details on the return format (e.g., JSON or text) or interpretation of the status fields, which could be helpful.

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

Parameters4/5

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

The input schema has zero parameters, so the description does not need to explain them. Baseline for 0 parameters is 4. Description adds no parameter info, but none is needed.

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 the verb 'show' and the resource 'security status', listing specific components (preflight, browser-deep, risk, cache, policy). This clearly distinguishes it from sibling tools like browser actions or phishark_rescan.

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

Usage Guidelines3/5

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

The description does not provide explicit guidance on when to use this tool vs. alternatives, such as phishark_rescan for rescanning. Usage is implied as a read-only status check, but no explicit exclusions or context are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 26 tool updatesv0.1.0
    • First observedbrowser_click
    • First observedbrowser_close
    • First observedbrowser_console_messages
    • First observedbrowser_drag
    • First observedbrowser_drop
    • First observedbrowser_evaluate
    • First observedbrowser_file_upload
    • First observedbrowser_fill_form
    • First observedbrowser_find
    • First observedbrowser_handle_dialog
    • First observedbrowser_hover
    • First observedbrowser_navigate
    • First observedbrowser_navigate_back
    • First observedbrowser_network_request
    • First observedbrowser_network_requests
    • First observedbrowser_press_key
    • First observedbrowser_resize
    • First observedbrowser_run_code_unsafe
    • First observedbrowser_select_option
    • First observedbrowser_snapshot
    • First observedbrowser_tabs
    • First observedbrowser_take_screenshot
    • First observedbrowser_type
    • First observedbrowser_wait_for
    • First observedphishark_rescan
    • First observedphishark_security_status
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation4/5

Most tools have distinct purposes, but there is slight potential for confusion between 'browser_type' and 'browser_fill_form', and between 'browser_take_screenshot' and 'browser_snapshot', though descriptions clarify the differences. Overall, the set is largely well-disambiguated.

Naming Consistency5/5

All tool names follow a consistent 'browser_' or 'phishark_' prefix with verb_noun structure, ensuring predictability. The naming convention is uniform and easy to interpret.

Tool Count4/5

With 26 tools, the set is comprehensive for browser automation, covering a wide range of actions. While slightly above the typical 3-15 range, each tool serves a distinct need, making the count reasonable for the domain.

Completeness5/5

The tool surface covers nearly all standard browser automation operations including navigation, interaction, network requests, console, and accessibility, plus additional security scanning. No obvious gaps are present for the stated purpose.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/phishark-git/phishark-playwright-mcp'

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