The Playwright MCP server enables browser automation through structured accessibility snapshots, bypassing the need for screenshots or vision models. With this server, you can:
Web Navigation: Navigate to URLs, go back/forward, and manage browser tabs
Page Interactions: Click, hover, type text, drag-and-drop, and select dropdown options
Media Handling: Upload files and save pages as PDFs
Capture: Take screenshots and accessibility snapshots of the current page
Utilities: Resize browser window, wait for specified durations, press keyboard keys
Management: Install required browser executables, close pages/tabs
Custom Transports: Use programmatically with custom transports for flexibility
Provides browser automation capabilities for Firefox, allowing LLMs to interact with web pages through structured accessibility snapshots, perform navigation, and interact with page elements.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Playwright MCP search for 'latest AI news' on Google and click the first result"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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.
Web navigation and form-filling
Data extraction from structured content
Automated testing driven by LLMs
General-purpose browser interaction for agents
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Install the Playwright MCP server in VS Code using one of these buttons:
Alternatively, you can install the Playwright MCP server using the VS Code CLI:
# For VS Code
code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'# For VS Code Insiders
code-insiders --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'After installation, the Playwright MCP server will be available for use with your GitHub Copilot agent in VS Code.
The Playwright MCP server supports the following command-line options:
--browser <browser>: Browser or chrome channel to use. Possible values:
chrome, firefox, webkit, msedge
Chrome channels: chrome-beta, chrome-canary, chrome-dev
Edge channels: msedge-beta, msedge-canary, msedge-dev
Default: chrome
--caps <caps>: Comma-separated list of capabilities to enable, possible values: tabs, pdf, history, wait, files, install. Default is all.
--cdp-endpoint <endpoint>: CDP endpoint to connect to
--executable-path <path>: Path to the browser executable
--headless: Run browser in headless mode (headed by default)
--port <port>: Port to listen on for SSE transport
--user-data-dir <path>: Path to the user data directory
--vision: Run server that uses screenshots (Aria snapshots are used by default)
Playwright MCP will launch the browser with the new profile, located at
- `%USERPROFILE%\AppData\Local\ms-playwright\mcp-chrome-profile` on Windows
- `~/Library/Caches/ms-playwright/mcp-chrome-profile` on macOS
- `~/.cache/ms-playwright/mcp-chrome-profile` on LinuxAll the logged in information will be stored in that profile, you can delete it between sessions if you'd like to clear the offline state.
This mode is useful for background or batch operations.
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--headless"
]
}
}
}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 SSE transport.
npx @playwright/mcp@latest --port 8931And then in MCP client config, set the url to the SSE endpoint:
{
"mcpServers": {
"playwright": {
"url": "http://localhost:8931/sse"
}
}
}The tools are available in two modes:
Snapshot Mode (default): Uses accessibility snapshots for better performance and reliability
Vision Mode: Uses screenshots for visual-based interactions
To use Vision Mode, add the --vision flag when starting the server:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--vision"
]
}
}
}Vision Mode works best with the computer use models that are able to interact with elements using X Y coordinate space, based on the provided screenshot.
import { createServer } from '@playwright/mcp';
// ...
const server = createServer({
launchOptions: { headless: true }
});
transport = new SSEServerTransport("/messages", res);
server.connect(transport);browser_click
Description: Perform click on a web page
Parameters:
element (string): Human-readable element description used to obtain permission to interact with the element
ref (string): Exact target element reference from the page snapshot
browser_hover
Description: Hover over element on page
Parameters:
element (string): Human-readable element description used to obtain permission to interact with the element
ref (string): Exact target element reference from the page snapshot
browser_drag
Description: Perform drag and drop between two elements
Parameters:
startElement (string): Human-readable source element description used to obtain permission to interact with the element
startRef (string): Exact source element reference from the page snapshot
endElement (string): Human-readable target element description used to obtain permission to interact with the element
endRef (string): Exact target element reference from the page snapshot
browser_type
Description: Type text into editable element
Parameters:
element (string): Human-readable element description used to obtain permission to interact with the element
ref (string): Exact target element reference from the page snapshot
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.
browser_select_option
Description: Select an option in a dropdown
Parameters:
element (string): Human-readable element description used to obtain permission to interact with the element
ref (string): Exact target element reference from the page snapshot
values (array): Array of values to select in the dropdown. This can be a single value or multiple values.
browser_snapshot
Description: Capture accessibility snapshot of the current page, this is better than screenshot
Parameters: None
browser_take_screenshot
Description: Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.
Parameters:
raw (boolean, optional): Whether to return without compression (in PNG format). Default is false, which returns a JPEG image.
browser_screen_move_mouse
Description: Move mouse to a given position
Parameters:
element (string): Human-readable element description used to obtain permission to interact with the element
x (number): X coordinate
y (number): Y coordinate
browser_screen_capture
Description: Take a screenshot of the current page
Parameters: None
browser_screen_click
Description: Click left mouse button
Parameters:
element (string): Human-readable element description used to obtain permission to interact with the element
x (number): X coordinate
y (number): Y coordinate
browser_screen_drag
Description: Drag left mouse button
Parameters:
element (string): Human-readable element description used to obtain permission to interact with the element
startX (number): Start X coordinate
startY (number): Start Y coordinate
endX (number): End X coordinate
endY (number): End Y coordinate
browser_screen_type
Description: Type text
Parameters:
text (string): Text to type
submit (boolean, optional): Whether to submit entered text (press Enter after)
browser_press_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
browser_tab_list
Description: List browser tabs
Parameters: None
browser_tab_new
Description: Open a new tab
Parameters:
url (string, optional): The URL to navigate to in the new tab. If not provided, the new tab will be blank.
browser_tab_select
Description: Select a tab by index
Parameters:
index (number): The index of the tab to select
browser_tab_close
Description: Close a tab
Parameters:
index (number, optional): The index of the tab to close. Closes current tab if not provided.
browser_navigate
Description: Navigate to a URL
Parameters:
url (string): The URL to navigate to
browser_navigate_back
Description: Go back to the previous page
Parameters: None
browser_navigate_forward
Description: Go forward to the next page
Parameters: None
browser_press_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
browser_console_messages
Description: Returns all console messages
Parameters: None
browser_file_upload
Description: Choose one or multiple files to upload
Parameters:
paths (array): The absolute paths to the files to upload. Can be a single file or multiple files.
browser_pdf_save
Description: Save page as PDF
Parameters: None
browser_wait
Description: Wait for a specified time in seconds
Parameters:
time (number): The time to wait in seconds (capped at 10 seconds)
browser_close
Description: Close the page
Parameters: None
browser_install
Description: Install the browser specified in the config. Call this if you get an error about the browser not being installed.
Parameters: None
Perform click on a web page
| Name | Required | Description | Default |
|---|---|---|---|
| element | Yes | Human-readable element description used to obtain permission to interact with the element | |
| ref | Yes | Exact target element reference from the page snapshot | |
| doubleClick | No | Whether to perform a double click instead of a single click | |
| button | No | Button to click, defaults to left | |
| modifiers | No | Modifier keys to press |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, openWorldHint=true, and destructiveHint=true, indicating this is a mutable, potentially destructive action with open-world behavior. The description adds minimal context beyond this, stating it performs a click but not elaborating on effects like navigation or UI changes. It doesn't contradict annotations, as 'Perform click' aligns with destructiveHint=true for web interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, front-loaded with the core action ('Perform click') and target ('on a web page'). Every word earns its place with zero waste, making it easy to parse quickly. This is optimal for a simple, well-annotated tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interactive web action with 5 parameters), annotations cover safety and behavior, and schema covers parameters fully. However, with no output schema, the description doesn't explain return values or side effects (e.g., what happens after a click). It's adequate but lacks completeness for a destructive tool in a browser automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., element for permission, ref for exact target, doubleClick for single/double click). The description adds no parameter-specific information beyond the schema, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform click on a web page' clearly states the action (click) and target (web page), making the purpose immediately understandable. It distinguishes from siblings like browser_hover or browser_press_key by specifying a click action. However, it doesn't explicitly differentiate from browser_double_click (implied via parameter) or browser_select_option, which might involve clicking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention when to choose browser_click over browser_double_click (handled via parameter), browser_hover, or browser_select_option, nor does it specify prerequisites like needing a page snapshot from browser_snapshot first. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds valuable context by specifying 'the page' as the target of closure. This clarifies that the operation affects the current page/tab rather than the entire browser application, which is useful behavioral information beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just three words ('Close the page'), front-loading the essential action and target with zero wasted words. Every element earns its place in this minimal but complete statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, destructive operation) and the presence of annotations covering safety aspects, the description is adequate but minimal. It lacks information about what happens after closure (e.g., whether browser session persists, if there are confirmation dialogs) and doesn't reference sibling tools for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 (close) and target (page), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like browser_tabs (which might manage multiple tabs) or explicitly mention that this closes the current browser page/tab rather than the entire browser session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't specify whether this closes the current tab or the entire browser, nor does it mention prerequisites like needing an active browser session or warn about potential data loss from unsaved changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all console messages
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info". | info |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, non-destructive, and open-world hints, but the description adds value by specifying 'all console messages,' implying a comprehensive retrieval. It doesn't contradict annotations (which indicate safe read operations) and provides context about scope, though it lacks details on format, pagination, or real-time behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Returns all console messages' is front-loaded and directly conveys the core function. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter), rich annotations (readOnlyHint, openWorldHint), and no output schema, the description is minimally adequate. It covers the basic action but lacks details on return format, error handling, or dependencies, leaving gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'level' parameter fully documented in the schema (including enum values, default, and description). The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline for high coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns all console messages' clearly states the verb ('returns') and resource ('console messages'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'browser_network_requests' or 'browser_tabs' beyond the resource type, and the title annotation 'Get console messages' is similar but not identical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing an active browser session), exclusions, or how it relates to siblings like 'browser_evaluate' or 'browser_run_code' that might generate console messages. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform drag and drop between two elements
| Name | Required | Description | Default |
|---|---|---|---|
| startElement | Yes | Human-readable source element description used to obtain the permission to interact with the element | |
| startRef | Yes | Exact source element reference from the page snapshot | |
| endElement | Yes | Human-readable target element description used to obtain the permission to interact with the element | |
| endRef | Yes | Exact target element reference from the page snapshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive (destructiveHint: true) and non-read-only (readOnlyHint: false) tool with open-world context (openWorldHint: true). The description adds minimal behavioral context beyond this, as it doesn't specify what 'drag and drop' entails (e.g., visual effects, state changes) or any constraints like rate limits. However, it doesn't contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive action with 4 required parameters), annotations cover safety and context hints, and schema fully describes parameters. However, without an output schema, the description doesn't explain return values or error conditions, and it lacks usage context. This leaves moderate gaps for a tool that modifies browser state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all four parameters (startElement, startRef, endElement, endRef). The description adds no additional parameter semantics beyond what the schema provides, such as explaining the relationship between 'element' and 'ref' parameters or usage examples. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Perform drag and drop') and the resources involved ('between two elements'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like browser_click or browser_hover, which are also interaction tools but for different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_click or browser_hover for element interactions. It lacks context about prerequisites (e.g., needing a page snapshot) or exclusions, leaving the agent to infer usage based on the action alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate JavaScript expression on page or element
| Name | Required | Description | Default |
|---|---|---|---|
| function | Yes | () => { /* code */ } or (element) => { /* code */ } when element is provided | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| ref | No | Exact target element reference from the page snapshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies that evaluation can target 'page or element', which clarifies scope. Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description doesn't contradict them. It could provide more on side effects or security implications, but adds useful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function. It's front-loaded with no wasted words, making it easy for an agent to parse quickly. Every word earns its place in this minimal but complete statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (JavaScript evaluation with destructive potential) and lack of output schema, the description is adequate but minimal. Annotations provide safety context, but the description could better explain return values or error handling. It meets minimum viability but leaves gaps for a powerful tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add significant meaning beyond the schema, but it hints at the relationship between 'function' and 'element' parameters. Baseline 3 is appropriate since the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Evaluate JavaScript expression on page or element'. It specifies the verb ('evaluate') and resource ('JavaScript expression'), though it doesn't explicitly differentiate from sibling tools like 'browser_run_code'. The purpose is unambiguous but could better distinguish from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention sibling tools like 'browser_run_code' or clarify scenarios where this tool is preferred. There's no context about prerequisites or typical use cases, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one or multiple files
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a destructive, non-read-only, open-world operation, which the description doesn't contradict. It adds minimal behavioral context by implying file selection (via 'file chooser' in schema), but doesn't detail side effects like UI interactions, permissions, or error handling beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('upload files') and includes a useful detail ('one or multiple'), making it appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive file upload), lack of output schema, and rich annotations, the description is minimally adequate. It states what the tool does but lacks details on outcomes, error cases, or integration with browser context, leaving gaps for an agent to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'paths' parameter. The description adds no additional meaning about parameters beyond what's in the schema, such as file format constraints or upload behavior specifics, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('upload') and resource ('files'), specifying it can handle 'one or multiple files'. It distinguishes from most browser siblings that interact with page elements rather than file operations, though it doesn't explicitly differentiate from potential file-related tools not present in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active browser session), exclusions, or how it relates to other browser tools like form filling or dialog handling that might involve file uploads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill multiple form fields
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Fields to fill in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true (implying changes) and readOnlyHint=false (confirming it's not read-only), which the description aligns with by implying mutation ('fill'). However, the description adds minimal behavioral context beyond annotations—it doesn't specify effects like overwriting existing values, requiring page focus, or handling errors. No contradiction with annotations exists, but value addition is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just three words—and front-loaded with the core action. Every word earns its place by specifying the action ('fill'), target ('form fields'), and scope ('multiple'), with no redundant or verbose phrasing, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutating multiple fields with varied types) and lack of output schema, the description is inadequate. It doesn't explain return values, error handling, or dependencies like needing a browser snapshot. Annotations cover safety but not operational context, leaving significant gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter documentation in the schema itself (e.g., field types, value formats). The description adds no parameter-specific semantics beyond the generic 'multiple form fields,' which doesn't clarify syntax or usage beyond what the schema provides. Baseline score of 3 applies as the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 verb ('fill') and resource ('form fields'), and the 'multiple' qualifier distinguishes it from single-field operations. However, it doesn't explicitly differentiate from sibling tools like browser_type (which might type text) or browser_select_option (which handles dropdowns), leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a browser session or page snapshot), exclusions (e.g., not for non-form elements), or comparisons to siblings like browser_type for single fields or browser_select_option for comboboxes, 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.
Handle a dialog
| Name | Required | Description | Default |
|---|---|---|---|
| accept | Yes | Whether to accept the dialog. | |
| promptText | No | The text of the prompt in case of a prompt dialog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, suggesting a mutation operation, which aligns with 'Handle' implying interaction. However, the description adds no behavioral context beyond this—it doesn't explain what 'handle' entails (e.g., accepting/dismissing dialogs, potential side effects, or error conditions), relying solely on annotations for basic safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, 'Handle a dialog', which is front-loaded and wastes no space. However, this brevity comes at the cost of clarity and completeness, but as per scoring rules, it earns full points for conciseness alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (handling browser dialogs with destructive potential) and lack of output schema, the description is inadequate. It doesn't explain return values, error handling, or interaction specifics, leaving significant gaps despite annotations providing some safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions: 'accept' for dialog acceptance and 'promptText' for prompt dialog input. The description adds no additional meaning beyond the schema, such as explaining how these parameters interact or typical use cases, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' is a tautology that restates the tool name without specifying what 'handle' means or what type of dialog is involved. It lacks a clear verb+resource combination and doesn't differentiate from sibling tools like browser_click or browser_type, which also interact with browser elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention specific dialog types (e.g., alert, confirm, prompt) or contexts, and there's no indication of prerequisites or exclusions, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over element on page
| Name | Required | Description | Default |
|---|---|---|---|
| element | Yes | Human-readable element description used to obtain permission to interact with the element | |
| ref | Yes | Exact target element reference from the page snapshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=true, and openWorldHint=true, indicating this is a mutable, potentially destructive action in an open-world context. The description adds minimal behavioral context beyond this—it doesn't explain what 'destructive' means here (e.g., could trigger page changes) or any side effects like rate limits. However, it doesn't contradict the annotations, so it meets the baseline with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase—and front-loaded with the core action. There is no wasted language or redundancy, making it efficient for quick comprehension by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interactive browser action with destructive potential), the description is incomplete. It lacks details on expected outcomes (e.g., what happens after hovering), error conditions, or prerequisites (e.g., needing a page snapshot first). With no output schema and minimal description, it leaves significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (element as human-readable description, ref as exact target reference). The description adds no additional parameter semantics beyond what the schema provides, such as examples or formatting details. With high schema coverage, 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.
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 target (element on page), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like browser_click or browser_press_key, which are also element interaction tools but perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention scenarios where hovering is appropriate (e.g., triggering dropdowns, tooltips) or when other tools like browser_click might be better. Without this context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install the browser specified in the config. Call this if you get an error about the browser not being installed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying it's for error recovery, but annotations already cover key traits: destructiveHint=true indicates potential system changes, and openWorldHint=true suggests external effects. No contradiction exists, and the description provides some operational context without rich behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and waste-free: the first states the action, and the second provides usage context. Every sentence earns its place by delivering essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive installation operation with no output schema), the description is adequate but minimal. It covers the purpose and usage trigger but lacks details on what 'install' entails, potential side effects, or success/failure indicators, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the schema fully documents the input structure. The description doesn't need to add parameter details, so it meets the baseline for no parameters, though it could mention config specifics if relevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install') and resource ('browser specified in the config'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'browser_click' or 'browser_navigate', which are interaction tools rather than setup tools, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('if you get an error about the browser not being installed'), which is helpful for troubleshooting. It doesn't specify when not to use it or name alternatives, but the context is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all network requests since loading the page
| Name | Required | Description | Default |
|---|---|---|---|
| includeStatic | No | Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds context about the temporal scope ('since loading the page') and implies data collection behavior, but doesn't disclose details like return format, pagination, or whether it includes failed requests. With annotations providing core behavioral traits, the description adds moderate value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does without redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (network data retrieval), annotations cover safety and scope well, but there's no output schema. The description lacks details on return values (e.g., structure, data types) and behavioral nuances like real-time updates or filtering options. It's minimally adequate but leaves gaps for an agent to understand full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'includeStatic' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, such as examples or edge cases. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('all network requests') with a temporal scope ('since loading the page'). It distinguishes from most siblings by focusing on network monitoring rather than page interaction, though it doesn't explicitly differentiate from tools like browser_console_messages that might overlap in debugging contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention when network request data is needed (e.g., debugging performance, monitoring API calls) or when other tools like browser_console_messages might be more appropriate. There's no explicit context or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a key on the keyboard
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Name of the key to press or a character to generate, such as `ArrowLeft` or `a` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive (destructiveHint: true), non-read-only (readOnlyHint: false) operation with open-world behavior (openWorldHint: true). The description adds minimal behavioral context beyond this, only confirming the action matches the annotations without contradiction. It doesn't elaborate on effects like focus requirements or interaction with browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description is minimally adequate given the simple parameter schema and clear annotations. However, it lacks context about typical use cases, error conditions, or integration with sibling tools, which would help an agent use it effectively in a browser automation workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'key' parameter fully documented in the schema itself. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press a key on the keyboard' clearly states the action (press) and target (key on keyboard), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'browser_type' which also involves keyboard input, so it doesn't achieve the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_type' or 'browser_fill_form'. There's no mention of specific contexts, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize the browser window
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Width of the browser window | |
| height | Yes | Height of the browser window |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict (it implies a mutation). The description adds minimal behavioral context beyond annotations, as it doesn't specify effects like window state changes or potential visual disruptions. With annotations covering safety, it meets a baseline but lacks details on rate limits or system impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly. Every part of the sentence earns its place by conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a destructive operation with two parameters), annotations provide safety info, but there's no output schema. The description is minimal and doesn't cover return values or error conditions. It's adequate for basic understanding but lacks depth for full contextual use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for width and height parameters. The description doesn't add meaning beyond the schema, such as units (pixels), valid ranges, or default behaviors. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Resize') and resource ('the browser window'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like browser_close or browser_snapshot, but the action is distinct enough in context. The description avoids tautology by not just restating the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing an active browser session), exclusions (e.g., not for mobile browsers), or sibling tools that might be related (like browser_snapshot for capturing after resize). Usage is implied from the action alone without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Playwright code snippet
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | 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(); }` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive, open-world, non-read-only operation. The description adds minimal behavioral context beyond this—it mentions running code but doesn't specify execution environment, error handling, or resource implications. No contradiction with annotations exists, but the description doesn't enrich the behavioral understanding significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just four words—and front-loaded with the essential action and resource. There's no wasted language or unnecessary elaboration, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running arbitrary Playwright code (a potentially powerful and risky operation), the description is insufficient. With no output schema and annotations only covering basic hints, it lacks details on return values, execution limits, or error scenarios, leaving significant gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'code' fully documented in the schema, including its type, required status, and an example. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline for high coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run Playwright code snippet' clearly states the action (run) and resource (Playwright code snippet), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like browser_evaluate or browser_console_messages, which also execute code or interact with browser content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With many sibling tools for specific browser interactions (e.g., browser_click, browser_type), there's no indication that this is a more flexible, general-purpose tool for custom Playwright scripts versus using simpler, targeted tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option in a dropdown
| Name | Required | Description | Default |
|---|---|---|---|
| element | Yes | Human-readable element description used to obtain permission to interact with the element | |
| ref | Yes | Exact target element reference from the page snapshot | |
| values | Yes | Array of values to select in the dropdown. This can be a single value or multiple values. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive (destructiveHint: true), non-read-only (readOnlyHint: false), open-world operation (openWorldHint: true). The description adds that it selects 'an option in a dropdown,' which clarifies the specific UI interaction, but doesn't provide additional behavioral context like error handling, multi-select capabilities (implied by 'values' parameter), or side effects beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's front-loaded and efficiently communicates the core function without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive UI interaction with 3 required parameters), annotations cover safety and scope, and schema fully describes inputs. However, without an output schema, the description doesn't explain return values or success/failure behavior. It's minimally complete but lacks details on outcomes or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (element, ref, values). The description adds minimal value beyond the schema, as it doesn't explain parameter relationships or usage examples. The baseline score of 3 is appropriate since the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select an option in a dropdown' clearly states the action (select) and target resource (option in a dropdown), making the purpose immediately understandable. It distinguishes from siblings like browser_click or browser_type by specifying dropdown interaction, though it doesn't explicitly contrast with similar tools like browser_fill_form which might also handle dropdowns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a page snapshot from browser_snapshot first), nor does it differentiate from sibling tools like browser_fill_form that might handle form dropdowns. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture accessibility snapshot of the current page, this is better than screenshot
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Save snapshot to markdown file instead of returning it in the response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds value by specifying 'accessibility snapshot' and comparing to screenshot, but doesn't detail behavioral traits like output format, permissions needed, or rate limits. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary details, though the comparison 'better than screenshot' could be more precise. Overall, it's appropriately sized with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations covering safety and scope, and no output schema, the description provides basic context but lacks details on what an 'accessibility snapshot' entails (e.g., format, content) or how it differs functionally from a screenshot. It's adequate but has gaps in explaining the tool's behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with one parameter 'filename' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('capture accessibility snapshot') and resource ('current page'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'browser_take_screenshot' beyond saying 'this is better than screenshot,' which is comparative but not a clear functional distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning it's 'better than screenshot,' suggesting it as an alternative for accessibility-focused captures, but it lacks explicit guidance on when to use this tool versus 'browser_take_screenshot' or other siblings. No context on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, create, close, or select a browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Operation to perform | |
| index | No | Tab index, used for close/select. If omitted for close, current tab is closed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide key behavioral traits: readOnlyHint=false (mutation possible), openWorldHint=true (unpredictable environment), and destructiveHint=true (can cause data loss). The description adds context by specifying actions like 'close' that align with destructive behavior, but doesn't elaborate on risks, permissions, or rate limits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with all key actions. Every word earns its place, with no redundant or verbose phrasing. It efficiently communicates the tool's scope without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (multiple actions, destructive potential) and lack of output schema, the description is minimally adequate. Annotations cover safety and environment traits, but the description doesn't explain return values, error conditions, or interaction effects, leaving gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (action and index). The description mentions actions like 'list' and 'close' that map to the action enum, but adds no syntax, format, or semantic details beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs (list, create, close, select) and resource (browser tab). It distinguishes from siblings like browser_close (which closes the browser, not tabs) and browser_navigate (which navigates within a tab), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 is provided. The description lists actions but doesn't indicate when to choose 'list' versus 'new', or when to use this tool over sibling tools like browser_close for closing the entire browser. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Image format for the screenshot. Default is png. | png |
| filename | No | 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. | |
| element | No | Human-readable element description used to obtain permission to screenshot the element. If not provided, the screenshot will be taken of viewport. If element is provided, ref must be provided too. | |
| ref | No | Exact target element reference from the page snapshot. If not provided, the screenshot will be taken of viewport. If ref is provided, element must be provided too. | |
| fullPage | No | When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable context by specifying that actions cannot be performed based on the screenshot, which clarifies the tool's limitations beyond the annotations. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which are essential: the first states the core purpose, and the second provides critical usage guidance. There is no wasted text, and it is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations cover safety and scope, and the schema fully describes parameters, the description adds key contextual guidance on tool differentiation. However, without an output schema, it does not explain return values (e.g., file path or image data), leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description does not add any parameter-specific details beyond what the schema provides, such as explaining interactions between parameters like element and ref. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Take a screenshot') and resource ('current page'), distinguishing it from sibling tools like browser_snapshot. It explicitly differentiates by stating 'use browser_snapshot for actions,' making the purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: 'use browser_snapshot for actions.' This directly addresses sibling differentiation and sets clear boundaries, helping the agent choose correctly based on the need for a screenshot versus interactive actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into editable element
| Name | Required | Description | Default |
|---|---|---|---|
| element | Yes | Human-readable element description used to obtain permission to interact with the element | |
| ref | Yes | Exact target element reference from the page snapshot | |
| text | Yes | Text to type into the element | |
| submit | No | Whether to submit entered text (press Enter after) | |
| slowly | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive, non-read-only operation with open-world characteristics. The description adds minimal behavioral context beyond this - it mentions typing into editable elements but doesn't elaborate on what 'editable element' means, potential side effects, or interaction patterns. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loading the core action without any wasted words. Every element ('type', 'text', 'into', 'editable element') contributes essential meaning, making it efficiently structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive browser interaction tool with 5 parameters and no output schema, the description is minimal but functional. It covers the basic action but lacks details about return values, error conditions, or interaction patterns that would be helpful given the tool's complexity and destructive nature. The annotations provide safety context, but more behavioral detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond the basic action of typing text into editable elements. The baseline score of 3 is appropriate when the schema carries the full parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Type text into editable element' clearly states the verb ('type') and target ('editable element'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like browser_fill_form or browser_press_key that might have overlapping functionality with text input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_fill_form or browser_press_key. There's no mention of specific contexts, prerequisites, or exclusions that would help an agent choose between similar browser interaction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for text to appear or disappear or a specified time to pass
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | The time to wait in seconds | |
| text | No | The text to wait for | |
| textGone | No | The text to wait for to disappear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe, non-destructive operation. The description adds behavioral context by specifying what triggers the wait (text appearance/disappearance or time), which goes beyond annotations, but it lacks details on timeout behavior, error handling, or interaction with other browser states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality without any wasted words. It directly communicates the tool's purpose in a structured manner, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema) and rich annotations, the description is adequate but incomplete. It covers the basic purpose but lacks details on return values, error cases, or integration with sibling tools, which could help the agent use it more effectively in a browser automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'time', 'text', and 'textGone' parameters. The description adds minimal semantic value by implying these parameters are used for waiting conditions, but it doesn't provide additional context like default values, parameter interactions, or examples, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('wait for text to appear or disappear or a specified time to pass'), making it easy to understand that this tool handles waiting conditions in a browser context. However, it doesn't explicitly differentiate itself from sibling tools like browser_handle_dialog or browser_network_requests, which might also involve waiting behaviors, though the focus on text/time is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention scenarios where waiting for text is preferred over other browser actions, prerequisites for usage, or exclusions, leaving the agent to infer context from sibling tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0browser_click1 field changedInput schema / properties / modifiersAdded value: +{
+ "description": "Modifier keys to press",
+ "items": {
+ "enum": [
+ "Alt",
+ "Control",
+ "ControlOrMeta",
+ "Meta",
+ "Shift"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}browser_console_messages1 field changedInput schema / properties / levelAdded value: +{
+ "default": "info",
+ "description": "Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to \"info\".",
+ "enum": [
+ "error",
+ "warning",
+ "info",
+ "debug"
+ ],
+ "type": "string"
+}browser_file_upload2 fields changedInput schema / properties / paths / descriptionPrevious value: -"The absolute paths to the files to upload. Can be a single file or multiple files."New value: +"The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled."Input schema / requiredRemoved value: -[
- "paths"
-]browser_fill_formbrowser_navigate_forwardbrowser_network_requests1 field changedInput schema / properties / includeStaticAdded value: +{
+ "default": false,
+ "description": "Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false.",
+ "type": "boolean"
+}browser_run_codebrowser_snapshot1 field changedInput schema / properties / filenameAdded value: +{
+ "description": "Save snapshot to markdown file instead of returning it in the response.",
+ "type": "string"
+}browser_tab_closebrowser_tab_listbrowser_tab_newbrowser_tab_selectbrowser_tabsbrowser_take_screenshot1 field changedInput schema / properties / filename / descriptionPrevious value: -"File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg}` if not specified."New value: +"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."browser_clickbrowser_closebrowser_console_messagesbrowser_dragbrowser_evaluatebrowser_file_uploadbrowser_handle_dialogbrowser_hoverbrowser_installbrowser_navigatebrowser_navigate_backbrowser_navigate_forwardbrowser_network_requestsbrowser_press_keybrowser_resizebrowser_select_optionbrowser_snapshotbrowser_tab_closebrowser_tab_listbrowser_tab_newbrowser_tab_selectbrowser_take_screenshotbrowser_typebrowser_wait_forMost tools have distinct purposes targeting specific browser interactions like clicking, navigating, or uploading files, with clear boundaries. However, browser_snapshot and browser_take_screenshot could be confused as both capture page states, though descriptions clarify that snapshot is for accessibility and actions while screenshot is visual only.
All tool names follow a consistent snake_case pattern with a 'browser_' prefix, using clear verb_noun combinations like browser_click, browser_navigate, and browser_wait_for. This predictability makes it easy to understand and navigate the toolset.
With 22 tools, the count is borderline high for a browser automation server, potentially overwhelming but still manageable. It covers many actions, but some tools like browser_install and browser_run_code might be less frequently used, slightly bloating the set.
The toolset provides comprehensive coverage for browser automation, including navigation, interaction (click, type, drag), debugging (console, network), media capture (screenshot, snapshot), and utilities (install, tabs). No obvious gaps exist for core Playwright workflows, ensuring agents can handle most web tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markbustamante77/mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server