Provides containerized browser automation capabilities through a Docker image, supporting headless Chromium for web interaction in isolated environments.
Allows browser automation with Firefox, enabling interaction with web pages through structured accessibility snapshots and providing tools for navigation, clicking, typing, screenshot capture, and form manipulation.
Integrates with GitHub Copilot in VS Code, enabling the AI assistant to interact with web browsers and automate web tasks through the MCP protocol.
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 go to github.com and search for 'playwright automation'"
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.
Node.js 18 or newer
VS Code, Cursor, Windsurf, Claude Desktop or any other MCP client
First, install the Playwright MCP server with your client. A typical configuration looks like this:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
You can also install the Playwright MCP server using the VS Code CLI:
# For VS Code
code --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.
Go to Cursor Settings -> MCP -> Add new MCP Server. Name to your liking, use command type with the command npx @playwright/mcp. You can also verify config or add command like arguments via clicking Edit.
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Follow Windsuff MCP documentation. Use following configuration:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Follow the MCP install guide, use following configuration:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Playwright MCP server supports following arguments. They can be provided in the JSON configuration above, as a part of the "args" list:
> npx @playwright/mcp@latest --help
--allowed-origins <origins> semicolon-separated list of origins to allow the
browser to request. Default is to allow all.
--blocked-origins <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.
--block-service-workers block service workers
--browser <browser> browser or chrome channel to use, possible
values: chrome, firefox, webkit, msedge.
--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.
--config <path> path to the configuration file.
--device <device> device to emulate, for example: "iPhone 15"
--executable-path <path> path to the browser executable.
--headless run browser in headless mode, headed by default
--host <host> host to bind server to. Default is localhost. Use
0.0.0.0 to bind to all interfaces.
--ignore-https-errors ignore https errors
--isolated keep the browser profile in memory, do not save
it to disk.
--image-responses <mode> 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.
--no-sandbox disable the sandbox for all process types that
are normally sandboxed.
--output-dir <path> path to the directory for output files.
--port <port> port to listen on for SSE transport.
--proxy-bypass <bypass> comma-separated domains to bypass proxy, for
example ".com,chromium.org,.domain.com"
--proxy-server <proxy> specify proxy server, for example
"http://myproxy:3128" or "socks5://myproxy:8080"
--save-trace Whether to save the Playwright Trace of the
session into the output directory.
--storage-state <path> path to the storage state file for isolated
sessions.
--user-agent <ua string> specify user agent string
--user-data-dir <path> path to the user data directory. If not
specified, a temporary directory will be created.
--viewport-size <size> specify browser viewport size in pixels, for
example "1280, 720"
--vision Run server that uses screenshots (Aria snapshots
are used by default)You can run Playwright MCP with persistent profile like a regular browser (default), or in the isolated contexts for the testing sessions.
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}-profile
# macOS
- ~/Library/Caches/ms-playwright/mcp-{channel}-profile
# Linux
- ~/.cache/ms-playwright/mcp-{channel}-profileIsolated
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": [
"@playwright/mcp@latest",
"--isolated",
"--storage-state={path/to/storage.json}"
]
}
}
}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 @playwright/mcp@latest --config path/to/config.json{
// Browser configuration
browser?: {
// Browser type to use (chromium, firefox, or webkit)
browserName?: 'chromium' | 'firefox' | 'webkit';
// Keep the browser profile in memory, do not save it to disk.
isolated?: boolean;
// Path to user data directory for browser profile persistence
userDataDir?: string;
// Browser launch options (see Playwright docs)
// @see https://playwright.dev/docs/api/class-browsertype#browser-type-launch
launchOptions?: {
channel?: string; // Browser channel (e.g. 'chrome')
headless?: boolean; // Run in headless mode
executablePath?: string; // Path to browser executable
// ... other Playwright launch options
};
// Browser context options
// @see https://playwright.dev/docs/api/class-browser#browser-new-context
contextOptions?: {
viewport?: { width: number, height: number };
// ... other Playwright context options
};
// CDP endpoint for connecting to existing browser
cdpEndpoint?: string;
// Remote Playwright server endpoint
remoteEndpoint?: string;
},
// Server configuration
server?: {
port?: number; // Port to listen on
host?: string; // Host to bind to (default: localhost)
},
// List of enabled capabilities
capabilities?: Array<
'core' | // Core browser automation
'tabs' | // Tab management
'pdf' | // PDF generation
'history' | // Browser history
'wait' | // Wait utilities
'files' | // File handling
'install' | // Browser installation
'testing' // Testing
>;
// Enable vision mode (screenshots instead of accessibility snapshots)
vision?: boolean;
// Directory for output files
outputDir?: string;
// Network configuration
network?: {
// List of origins to allow the browser to request. Default is to allow all. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
allowedOrigins?: string[];
// List of origins to block the browser to request. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
blockedOrigins?: string[];
};
/**
* Do not send image responses to the client.
*/
noImageResponses?: boolean;
}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"
}
}
}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"]
}
}
}You can build the Docker image yourself.
docker build -t mcr.microsoft.com/playwright/mcp .import http from 'http';
import { createConnection } from '@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);
// ...
});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.
browser_snapshot
Title: Page snapshot
Description: Capture accessibility snapshot of the current page, this is better than screenshot
Parameters: None
Read-only: true
browser_click
Title: 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
Read-only: false
browser_drag
Title: Drag mouse
Description: Perform drag and drop between two elements
Parameters:
startElement (string): Human-readable source element description used to obtain the 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 the permission to interact with the element
endRef (string): Exact target element reference from the page snapshot
Read-only: false
browser_hover
Title: Hover mouse
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
Read-only: true
browser_type
Title: Type text
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.
Read-only: false
browser_select_option
Title: 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.
Read-only: false
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_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: true
browser_file_upload
Title: Upload files
Description: Upload one or multiple files
Parameters:
paths (array): The absolute paths to the files to upload. Can be a single file or multiple files.
Read-only: false
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_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
Parameters: None
Read-only: true
browser_navigate_forward
Title: Go forward
Description: Go forward to the next page
Parameters: None
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:
raw (boolean, optional): Whether to return without compression (in PNG format). Default is false, which returns a JPEG image.
filename (string, optional): File name to save the screenshot to. Defaults to page-{timestamp}.{png|jpeg} if not specified.
element (string, optional): 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 (string, optional): 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.
Read-only: true
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.
Read-only: true
browser_network_requests
Title: List network requests
Description: Returns all network requests since loading the page
Parameters: None
Read-only: true
browser_console_messages
Title: Get console messages
Description: Returns all console messages
Parameters: None
Read-only: true
browser_install
Title: Install the browser specified in the config
Description: Install the browser specified in the config. Call this if you get an error about the browser not being installed.
Parameters: None
Read-only: false
browser_close
Title: Close browser
Description: Close the page
Parameters: None
Read-only: true
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: true
browser_tab_list
Title: List tabs
Description: List browser tabs
Parameters: None
Read-only: true
browser_tab_new
Title: Open a new tab
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.
Read-only: true
browser_tab_select
Title: Select a tab
Description: Select a tab by index
Parameters:
index (number): The index of the tab to select
Read-only: true
browser_tab_close
Title: Close a tab
Description: Close a tab
Parameters:
index (number, optional): The index of the tab to close. Closes current tab if not provided.
Read-only: false
browser_generate_playwright_test
Title: Generate a Playwright test
Description: Generate a Playwright test for given scenario
Parameters:
name (string): The name of the test
description (string): The description of the test
steps (array): The steps of the test
Read-only: true
browser_screen_capture
Title: Take a screenshot
Description: Take a screenshot of the current page
Parameters: None
Read-only: true
browser_screen_move_mouse
Title: 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
Read-only: true
browser_screen_click
Title: 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
Read-only: false
browser_screen_drag
Title: Drag mouse
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
Read-only: false
browser_screen_type
Title: Type text
Description: Type text
Parameters:
text (string): Text to type into the element
submit (boolean, optional): Whether to submit entered text (press Enter after)
Read-only: false
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_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: true
browser_file_upload
Title: Upload files
Description: Upload one or multiple files
Parameters:
paths (array): The absolute paths to the files to upload. Can be a single file or multiple files.
Read-only: false
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
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 indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a mutating action ('Perform click'). The description adds minimal behavioral context beyond annotations, but doesn't contradict them. It lacks details on error handling or side effects, but annotations cover key safety aspects.
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 zero wasted words. It's appropriately sized for a simple action and front-loads the core functionality 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?
For a destructive tool with no output schema, the description is minimally adequate but lacks context about outcomes or errors. Annotations provide safety hints, but the description doesn't address what happens post-click (e.g., page changes, navigation) or integration with other browser tools, 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?
Schema description coverage is 100%, providing full parameter documentation. The description adds no parameter-specific information beyond what's in the schema, such as explaining the relationship between 'element' and 'ref' or typical use cases for modifiers. 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 'Perform click on a web page' states the action (click) and target (web page), but is vague about scope and lacks sibling differentiation. It doesn't specify whether this clicks on specific elements or general coordinates, nor how it differs from similar tools like browser_press_key or browser_select_option.
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. The description doesn't mention prerequisites (e.g., needing a browser session or page snapshot), nor does it clarify use cases relative to siblings like browser_hover or browser_press_key for interaction scenarios.
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 indicate destructiveHint=true and readOnlyHint=false, confirming this is a destructive write operation. The description adds context by specifying 'the page' as the target, which clarifies scope beyond annotations. It doesn't contradict annotations, and while it doesn't detail side effects (e.g., data loss, confirmation dialogs), it provides useful behavioral context that annotations alone don't 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—just three words—and front-loaded with the core action. Every word earns its place by directly conveying the tool's function without any fluff or redundancy, making it highly efficient and easy to parse.
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 (simple destructive action), annotations cover safety (destructive) and mutability (not read-only), and there are 0 parameters, the description is minimally adequate. However, it lacks details on output (no schema provided) and could benefit from more context on what 'page' refers to (e.g., current tab vs. browser window). It meets basic needs but has 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but this is appropriate given the lack of parameters. Baseline is 4 for 0 parameters, as the description doesn't need to compensate for any 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), but it's somewhat vague about scope—does it close the current tab, the entire browser, or something else? It distinguishes from siblings like browser_navigate or browser_tabs by focusing on termination rather than navigation or inspection, but lacks specificity on what exactly is being closed.
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 explicit guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., needing an open page), exclusions, or comparisons to siblings like browser_tabs (which might list tabs) or browser_navigate_back (for navigation). Usage is implied by the action alone, with no contextual advice.
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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds minimal behavioral context by implying it retrieves messages (consistent with annotations) but doesn't disclose details like whether it clears messages after retrieval, requires specific browser state, or has rate limits. 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool, 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 (1 optional parameter), rich annotations (covering safety and scope), and no output schema, the description is minimally adequate. However, it lacks context about what 'console messages' entail (e.g., browser console logs, timestamps, sources) and doesn't address potential limitations or prerequisites, 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%, with the 'level' parameter fully documented in the schema (enum values, default, description). The description adds no 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 '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' which also return browser-related data, nor does it specify that these are browser console messages specifically.
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 it's appropriate (e.g., for debugging browser interactions) or when not to use it (e.g., for network monitoring where 'browser_network_requests' would be better). There's no reference to sibling tools or contextual usage scenarios.
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 indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds value by specifying the action involves two elements, but it doesn't elaborate on behavioral traits like potential side effects, error conditions, or interaction constraints 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, clear sentence that efficiently conveys the core action without unnecessary words. It is front-loaded and appropriately sized for the tool's complexity.
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, destructive) and lack of output schema, the description is minimal but adequate. It covers the basic action but doesn't address return values, error handling, or detailed usage context, leaving gaps that annotations partially fill.
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 four parameters. The description implies parameters for start and end elements but adds no additional meaning beyond the schema's detailed descriptions of human-readable descriptions and exact references from page snapshots.
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 target ('between two elements'), which is specific and actionable. However, it doesn't differentiate itself 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, nor does it mention prerequisites such as needing a page snapshot or specific element references. It lacks context about appropriate scenarios or exclusions.
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?
Annotations already indicate this is a destructive, non-read-only operation with open-world implications. The description adds some context by specifying it evaluates JavaScript on 'page or element', but doesn't elaborate on what 'destructive' means in practice (e.g., could modify page state, trigger side effects) or address rate limits, authentication needs, or specific behavioral traits 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 extremely concise - a single, clear sentence that communicates the core functionality without any wasted words. It's front-loaded with the essential information and earns its place 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?
For a complex, destructive JavaScript evaluation tool with no output schema, the description is minimal. While annotations cover safety aspects, the description doesn't explain what kind of results to expect, error handling, or the relationship between parameters. Given the tool's potential complexity and destructive nature, more context would be helpful despite the good annotations.
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, the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'page or element' which relates to the element/ref parameters, but doesn't provide additional syntax examples, constraints, or usage patterns that aren't already in the parameter descriptions.
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 ('Evaluate') and resource ('JavaScript expression on page or element'), making the purpose immediately understandable. It distinguishes this tool from siblings like browser_click or browser_type by focusing on JavaScript execution rather than direct interaction. However, it doesn't explicitly differentiate from browser_run_code, which might be a similar sibling.
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 siblings like browser_run_code that might serve similar purposes, there's no indication of when this evaluation approach is preferred, nor any mention of prerequisites or constraints for usage.
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 destructiveHint=true and readOnlyHint=false, which the description doesn't contradict (uploading implies mutation). The description adds that it can handle single or multiple files, which is useful context beyond annotations. However, it lacks details on permissions, rate limits, or what happens if upload fails, leaving behavioral gaps.
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 wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information.
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 operation with no output schema), the description is adequate but incomplete. It covers the basic action but lacks details on error handling, success criteria, or integration with sibling tools. With annotations providing safety hints, it meets minimum viability but could be more comprehensive.
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 'paths' well-documented in the schema. The description adds minimal value by implying the parameter can accept multiple files, but this is already clear from the schema's array type. Baseline 3 is appropriate as the schema carries most of the 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 action ('upload') and resource ('one or multiple files'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like browser_drag or browser_fill_form, which might also involve file operations in some contexts, so it doesn't reach 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. It doesn't mention prerequisites (e.g., needing an open browser), exclusions, or comparisons to sibling tools like browser_drag for file handling. This leaves the agent with minimal 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.
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 and readOnlyHint=false, which the description aligns with by implying mutation ('fill'). The description adds value by hinting at bulk operation ('multiple form fields'), but lacks details on side effects, error handling, or dependencies. 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 a single, efficient phrase with no wasted words. It is front-loaded and appropriately sized for the tool's complexity, 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?
For a destructive tool with no output schema, the description is insufficient. It lacks details on return values, error conditions, or interaction with the browser context. Given the annotations cover safety but not operational context, more completeness is needed.
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 'fields' parameter fully documented in the schema. The description adds no additional meaning beyond implying multiple fields, which is already clear from the schema's array type. This 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 'Fill multiple form fields' states the action (fill) and target (form fields), but is vague about scope and lacks differentiation from siblings like browser_type or browser_select_option. It doesn't specify whether this is for web forms or other contexts, making it minimally adequate but unclear.
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 such as browser_type for text input or browser_select_option for dropdowns. The description implies bulk form filling but offers no context on prerequisites, timing, or exclusions, leaving usage ambiguous.
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 readOnlyHint=false, openWorldHint=true, and destructiveHint=true, which already inform the agent that this is a mutable, potentially destructive operation with open-ended outcomes. The description adds minimal value by implying interaction with dialogs but doesn't elaborate on behavioral traits like side effects, error conditions, or specific dialog types. No contradiction with annotations exists, but the description fails to compensate for the lack of output schema or detailed context.
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, which is efficient and front-loaded. However, it's overly terse to the point of under-specification, missing critical details that would help an agent. While not verbose, it fails to earn a perfect score due to lacking necessary explanatory content.
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), lack of output schema, and minimal annotations beyond basic hints, the description is incomplete. It doesn't cover return values, error handling, or the scope of 'dialogs' (e.g., alerts, confirms, prompts), leaving significant gaps for agent understanding in a context-rich browser automation environment.
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 documentation for 'accept' (boolean for accepting the dialog) and 'promptText' (string for prompt dialog text). The description adds no parameter semantics beyond what the schema provides, such as explaining when 'promptText' is required or how 'accept' interacts with different dialog types. Baseline 3 is appropriate given the schema's comprehensive 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 adding specificity. It doesn't clarify what type of dialog (e.g., JavaScript alert, confirmation, prompt) or what 'handling' entails beyond the basic verb. While it distinguishes from siblings like 'browser_click' or 'browser_navigate' by focusing on dialogs, it lacks the detailed verb+resource+scope needed for higher scoring.
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., that a dialog must be present), exclusions, or related tools for different dialog types. Given the sibling tools include various browser interactions, this lack of context leaves the agent guessing about appropriate usage scenarios.
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 indicate this is a destructive (destructiveHint: true), non-read-only (readOnlyHint: false) operation with open-world characteristics (openWorldHint: true). The description 'Hover over element on page' aligns with these annotations by implying an interactive action that could trigger page changes, but it doesn't add significant behavioral context beyond what annotations provide, such as specific side effects 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words ('Hover over element on page'), with zero wasted language. It's front-loaded and directly communicates the core action, making it highly efficient despite potential gaps in other dimensions.
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 hints), lack of output schema, and rich annotations, the description is insufficient. It doesn't explain what happens after hovering (e.g., triggering UI changes), potential errors, or integration with other browser tools, leaving 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?
With 100% schema description coverage, the input schema fully documents both parameters (element and ref). The description adds no additional parameter semantics, such as explaining the relationship between 'element' and 'ref' or providing usage examples. This 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 'Hover over element on page' clearly states the action (hover) and target (element on page), making the purpose immediately understandable. However, it doesn't differentiate this tool from its many sibling browser interaction tools (like browser_click or browser_press_key) beyond the specific hover action, which is why it doesn't reach a perfect 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_click or browser_press_key. It doesn't mention any prerequisites, context requirements, or scenarios where hovering is specifically needed over other interactions, 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.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds valuable context about when to use the tool (error recovery scenario) that goes beyond what annotations provide. However, it doesn't mention potential side effects like system changes or installation time, which would be helpful additional behavioral context.
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?
Two sentences, zero waste. The first sentence states the purpose, the second provides usage guidance. Every word earns its place, and the most important information (what it does) comes first.
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 parameters and no output schema, the description provides good context about purpose and usage. However, it doesn't mention what 'the config' refers to or what happens after installation (e.g., whether browser becomes available immediately), leaving some contextual gaps despite the tool's simplicity.
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 would be 4. The description appropriately doesn't discuss parameters since there are none, and instead focuses on the tool's purpose and usage context, which adds semantic value beyond the empty schema.
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 ('Install') and resource ('the browser specified in the config'), distinguishing it from all sibling tools which are browser interaction commands rather than setup/installation tools. It provides explicit differentiation by focusing on installation rather than runtime operations.
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 when-to-use guidance: 'Call this if you get an error about the browser not being installed.' This gives clear context for invocation and implicitly suggests alternatives (don't call it unless you encounter that specific error condition).
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 value by specifying 'since loading the page', indicating temporal scope, but doesn't disclose behavioral traits like rate limits, pagination, or response format. With annotations providing core safety, a 3 is appropriate for minimal added context.
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's front-loaded and appropriately sized, with every part contributing essential information, making it highly concise and well-structured.
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 (1 parameter, 100% schema coverage, no output schema) and rich annotations, the description is minimally adequate. It covers the basic action but lacks details on output format, error handling, or integration with siblings, leaving gaps despite structured data support.
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 'includeStatic' fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides, such as examples or edge cases. Baseline 3 is correct as 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 'returns' and resource 'all network requests since loading the page', providing specific functionality. However, it doesn't explicitly differentiate from sibling tools like browser_console_messages or browser_snapshot that might also capture network-related data, missing 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 no guidance on when to use this tool versus alternatives, such as browser_console_messages for console logs or browser_snapshot for visual captures. It lacks explicit context, prerequisites, or exclusions, offering only a basic functional statement without usage direction.
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 destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a state-changing action ('press'). The description adds no additional behavioral context about side effects, timing, or error conditions, but doesn't contradict annotations. With annotations covering the safety profile, this is acceptable.
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?
Extremely concise single sentence with zero wasted words. The description is front-loaded with the core action and gets straight to the point without any unnecessary elaboration or formatting.
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 single-parameter destructive action with good annotations but no output schema, the description is minimally adequate. It states what the tool does but lacks context about browser state requirements, expected outcomes, or error handling that would be helpful for an agent.
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 'key' fully documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema, meeting the baseline expectation when schema coverage is complete.
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 ('press') and target ('key on the keyboard'), making the purpose immediately understandable. It distinguishes from siblings like browser_type (continuous typing) and browser_click (mouse action). However, it doesn't specify this is for browser automation versus general keyboard 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?
No guidance on when to use this tool versus alternatives like browser_type or browser_click. The description provides no context about appropriate use cases, 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 already indicate destructiveHint=true (mutation) and readOnlyHint=false, so the agent knows this modifies state. The description adds no behavioral context beyond this, such as whether resizing affects page layout, requires specific permissions, or has side effects. With annotations covering the safety profile, a baseline 3 is appropriate as the description doesn't contradict but adds little value.
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 and directly conveys the core function without unnecessary elaboration, 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 moderate complexity (destructive operation with two parameters), annotations provide safety context, but there's no output schema. The description lacks details on return values (e.g., success confirmation) or error conditions, leaving gaps. It's minimally adequate but not fully complete for informed 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 parameter descriptions for width and height. The description adds no meaning beyond what the schema provides, such as unit explanations (pixels), valid ranges, or default behaviors. Since the schema does the heavy lifting, the baseline score of 3 is warranted.
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 'Resize the browser window' clearly states the action (resize) and resource (browser window), making the purpose immediately understandable. It distinguishes from siblings like browser_close or browser_navigate by specifying the resize operation. However, it lacks explicit differentiation from tools like browser_snapshot that might also involve window dimensions, preventing a perfect 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. It doesn't mention prerequisites (e.g., an active browser session), exclusions (e.g., not for mobile browsers), or comparisons to siblings like browser_take_screenshot for visual changes. This leaves the agent with minimal context for tool selection.
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 indicate destructiveHint=true and openWorldHint=true, which the description doesn't contradict. The description adds valuable context beyond annotations by specifying that the code will be executed with a page argument for interactions, which helps the agent understand the execution environment. However, it doesn't mention potential side effects like page navigation or resource consumption that destructiveHint=true implies.
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 'Run Playwright code snippet' is extremely concise at just four words, front-loading the core purpose without any wasted words. Every element earns its place by clearly communicating the tool's function in minimal 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 (executing arbitrary code with destructive potential) and the absence of an output schema, the description is somewhat incomplete. It doesn't explain what the tool returns (e.g., the result of the executed function) or error handling. However, annotations provide safety context, and the schema covers the parameter well, making it minimally adequate but with clear gaps for a code execution 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%, with the parameter 'code' fully documented in the schema as a JavaScript function containing Playwright code. The description doesn't add any additional parameter semantics beyond what's already in the schema. With high schema coverage, the baseline score of 3 is appropriate since the description doesn't compensate but also 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 'Run Playwright code snippet' clearly states the action (run) and resource (Playwright code snippet), making the purpose immediately understandable. It distinguishes from siblings by focusing on executing arbitrary code rather than specific browser actions like click or navigate. However, it doesn't explicitly mention browser automation context, which could make the distinction slightly less sharp.
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 for executing custom Playwright scripts, suggesting it should be used when specific browser actions aren't available as dedicated tools. However, it doesn't provide explicit guidance on when to use this vs alternatives like browser_click or browser_type, nor does it mention prerequisites like needing an active browser session. The context is clear but lacks explicit alternatives or exclusions.
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 provide readOnlyHint=false, openWorldHint=true, and destructiveHint=true, indicating this is a mutable, open-ended, and potentially destructive action. The description adds minimal behavioral context beyond this, as 'Select an option' implies mutation but doesn't detail effects like page changes or side effects. It doesn't contradict annotations, so a baseline 3 is appropriate given the annotations cover key traits.
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, front-loaded sentence with zero waste: 'Select an option in a dropdown' directly conveys the core purpose without fluff. Every word earns its place, making it highly efficient and easy to parse.
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 UI action with 3 required parameters), annotations cover safety and openness, but there's no output schema. The description is minimal and doesn't address return values or error conditions, leaving gaps. It's adequate for basic understanding but incomplete for robust agent use, scoring a minimum viable 3.
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 no additional parameter semantics beyond what the schema provides, such as examples or edge cases for values. Since the schema does the heavy lifting, the baseline score of 3 is justified.
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 ('Select an option') and target ('in a dropdown'), which is specific and distinguishes it from siblings like browser_click or browser_fill_form. However, it doesn't explicitly differentiate from browser_handle_dialog or browser_type, which could also involve selection interactions, making it slightly less precise than a perfect 5.
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 snapshot first), exclusions (e.g., not for non-dropdown elements), or comparisons to siblings like browser_click for general interactions, leaving 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.
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 provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, non-destructive operation. The description adds context by specifying it captures an 'accessibility snapshot,' which suggests it might include metadata like ARIA roles or contrast ratios, beyond a visual screenshot. However, it doesn't detail what exactly is captured, the format, or any behavioral traits like rate limits or permissions. With annotations covering safety, the description adds some value but lacks rich behavioral disclosure.
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: 'Capture accessibility snapshot of the current page, this is better than screenshot.' It's front-loaded with the core purpose and adds a comparative note without waste. Every part earns its place, making it highly concise and well-structured.
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 (capturing accessibility data), annotations provide safety hints, but there's no output schema. The description hints at the output being an 'accessibility snapshot' but doesn't explain return values, format, or what makes it 'better.' For a tool with potential rich output and no output schema, the description is incomplete, leaving gaps in understanding the result.
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?
There is 1 parameter with 100% schema description coverage, so the schema fully documents the 'filename' parameter. The description doesn't add any parameter-specific information, which is acceptable given the high coverage. Since there's only one optional parameter, the baseline is 4, as the description doesn't need to compensate for gaps, and it's not misleading.
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: 'Capture accessibility snapshot of the current page' with a specific verb ('capture') and resource ('accessibility snapshot'). It distinguishes from the sibling 'browser_take_screenshot' by noting 'this is better than screenshot,' though it doesn't explicitly name the sibling. The purpose is clear but could be more explicit about the 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 contrasting with 'screenshot' (likely referring to 'browser_take_screenshot'), suggesting it's preferred for accessibility purposes. However, it doesn't explicitly state when to use this tool versus alternatives like 'browser_take_screenshot' or other siblings, nor does it provide context on prerequisites or exclusions. The guidance is implied but not comprehensive.
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?
The description adds minimal behavioral context beyond annotations. Annotations already declare destructiveHint=true and readOnlyHint=false, indicating mutation capability. The description confirms this with 'close' action but doesn't add meaningful context about what gets destroyed (tab state, unsaved data), authentication needs, or rate limits. 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 perfectly concise with a single, front-loaded sentence that lists all four actions. Every word earns its place with zero redundancy or unnecessary elaboration. The structure immediately communicates the tool's scope without preamble.
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 (four distinct actions, destructive operations) and rich annotations but no output schema, the description is minimally adequate. It covers the basic purpose but lacks guidance on usage context, behavioral details, or return values. The annotations help but don't fully compensate for the description's gaps in a multi-action 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?
With 100% schema description coverage, the schema fully documents both parameters. The description adds no parameter-specific semantics beyond implying the four action values. It doesn't explain index usage nuances or default behaviors beyond what's in the schema. Baseline 3 is appropriate when 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 clearly states the tool's purpose with specific verbs (list, create, close, select) and resource (browser tab). It distinguishes from siblings by focusing on tab management rather than navigation, interaction, or monitoring. However, it doesn't explicitly differentiate from close-related siblings like browser_close.
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 prefer browser_close for closing browsers versus this tool for closing tabs, or when to use browser_navigate versus creating a new tab. No explicit when/when-not statements or alternative tool references are included.
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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds context about the action limitation (can't perform actions based on screenshot) and the viewport vs element screenshot behavior, but doesn't provide details about return format, error conditions, or performance characteristics.
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 consists of just two sentences that are completely front-loaded with essential information. Every word serves a purpose - the first sentence states the core function, the second provides critical usage guidance. There's zero wasted verbiage.
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 read-only tool with comprehensive parameter documentation and clear annotations, the description provides adequate context. The main gap is the lack of output schema, but the description compensates somewhat by clarifying the tool's limitations relative to browser_snapshot. It could benefit from mentioning what the tool returns (presumably an image file reference).
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, the input schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation when schema coverage is complete.
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 provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 explicitly provides when-not-to-use guidance: 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This gives clear alternative usage context and distinguishes between screenshot capture versus interactive snapshot tools.
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 semantics. The description adds minimal behavioral context beyond this, mentioning typing into an element but not detailing side effects like potential page changes or error conditions. It doesn't contradict annotations, but adds little value over them.
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, clear sentence with zero wasted words. It's front-loaded with the core action and target, making it highly efficient and easy to parse for an AI 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?
For a destructive tool with 5 parameters and no output schema, the description is minimal. It covers the basic purpose but lacks context on error handling, performance implications, or typical use cases. Given the rich schema and annotations, it's adequate but leaves gaps in practical guidance.
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 parameters. The description adds no additional meaning about parameters like 'element', 'ref', or 'text' beyond what's in the schema. Baseline 3 is appropriate when the schema does all 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 'Type text into editable element' clearly states the action (type) and target (editable element), distinguishing it from siblings like browser_click or browser_fill_form. However, it doesn't explicitly differentiate from browser_press_key which could also input text, so it's not a perfect 5.
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. It doesn't mention prerequisites (e.g., needing a page snapshot) or exclusions, leaving 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.
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 already declare readOnlyHint=true and destructiveHint=false, indicating a safe, non-mutating operation. The description adds context by specifying what the tool waits for (text appearance/disappearance or time), which is useful beyond annotations. However, it lacks details on timeout behavior, error handling, or interaction with other browser tools, leaving some behavioral aspects unclear.
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 unnecessary words. Every part earns its place by covering the key actions (wait for text appear/disappear or time pass), making it highly concise and well-structured for quick understanding.
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 (readOnlyHint, openWorldHint), the description is adequate but incomplete. It covers what the tool does but lacks details on return values (e.g., success/failure indicators), error cases, or integration with sibling tools. With no output schema, more return information would be helpful.
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 each parameter (time, text, textGone). The description adds minimal value by mentioning these parameters generally but doesn't provide additional semantics like usage examples, constraints (e.g., time must be positive), or how parameters interact (e.g., if both text and textGone are provided). 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 as waiting for text to appear/disappear or for time to pass, which is a specific action. It distinguishes itself from siblings like browser_click or browser_navigate by focusing on waiting rather than direct interaction. However, it doesn't explicitly differentiate from all siblings (e.g., browser_handle_dialog might also involve waiting).
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 waiting on network requests), or comparisons to similar tools like browser_handle_dialog for waiting on dialogs. Usage is implied but not explicitly defined.
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, but there is some overlap between browser_snapshot and browser_take_screenshot, as both involve capturing page states, though their descriptions clarify different use cases. The tools generally target specific actions like navigation, interaction, or monitoring, reducing confusion.
All tool names follow a consistent 'browser_' prefix with snake_case, using clear verbs like click, close, navigate, or wait_for. This predictable pattern makes it easy for agents to understand and predict tool functions without ambiguity.
With 22 tools, the count is borderline high for a web automation server, potentially overwhelming but still manageable given the comprehensive scope. It covers many aspects of browser interaction, though some tools might be consolidated for better focus.
The tool set provides complete coverage for web automation tasks, including navigation, interaction (click, type, drag), form handling, monitoring (console, network), and utilities (screenshot, wait). No obvious gaps exist for typical Playwright workflows, ensuring agents can handle end-to-end scenarios.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
A Model Context Protocol server for Wix AI tools
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Angeluis001/playwright-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
