Un servidor del Protocolo de Contexto de Modelo (MCP) que proporciona capacidades de automatización de navegadores utilizando Playwright. Este servidor permite a los LLM interactuar con páginas web a través de instantáneas de accesibilidad estructuradas, evitando la necesidad de capturas de pantalla o modelos ajustados visualmente.
Este paquete proporciona una interfaz MCP para Playwright. Si estás utilizando un agente de codificación, puede que te beneficies de usar CLI+SKILLS en su lugar.
CLI: Los agentes de codificación modernos favorecen cada vez más flujos de trabajo basados en CLI expuestos como SKILLS en lugar de MCP, porque las invocaciones de CLI son más eficientes en tokens: evitan cargar esquemas de herramientas grandes y árboles de accesibilidad verbosos en el contexto del modelo, permitiendo a los agentes actuar a través de comandos concisos y específicos. Esto hace que CLI + SKILLS sea más adecuado para agentes de codificación de alto rendimiento que deben equilibrar la automatización del navegador con grandes bases de código, pruebas y razonamiento dentro de ventanas de contexto limitadas.Más información sobre Playwright CLI con SKILLS.
MCP: MCP sigue siendo relevante para bucles agentivos especializados que se benefician de un estado persistente, introspección rica y razonamiento iterativo sobre la estructura de la página, como la automatización exploratoria, pruebas auto-curativas o flujos de trabajo autónomos de larga duración donde mantener un contexto continuo del navegador supera las preocupaciones de costo de tokens.
Rápido y ligero. Utiliza el árbol de accesibilidad de Playwright, no la entrada basada en píxeles.
Amigable para LLM. No se necesitan modelos de visión, opera puramente con datos estructurados.
Aplicación de herramientas determinista. Evita la ambigüedad común en los enfoques basados en capturas de pantalla.
Node.js 18 o superior
VS Code, Cursor, Windsurf, Claude Desktop, Goose, Grok, Junie o cualquier otro cliente MCP
Primero, instala el servidor Playwright MCP con tu cliente.
Configuración estándar funciona en la mayoría de las herramientas:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
Añadir a través de la pantalla de configuración de la extensión Amp de VS Code o actualizando tu archivo settings.json:
"amp.mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}Configuración CLI de Amp:
Añadir mediante el comando amp mcp add a continuación
amp mcp add playwright -- npx @playwright/mcp@latestAñadir a través de la configuración de Antigravity o actualizando tu archivo de configuración:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Usa la CLI de Claude Code para añadir el servidor Playwright MCP:
claude mcp add playwright npx @playwright/mcp@latestSigue la guía de instalación de MCP, usa la configuración estándar anterior.
Sigue las instrucciones en la sección Configuring MCP Servers
Ejemplo: Configuración local
Añade lo siguiente a tu archivo cline_mcp_settings.json:
{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"timeout": 30,
"args": [
"-y",
"@playwright/mcp@latest"
],
"disabled": false
}
}
}Usa la CLI de Codex para añadir el servidor Playwright MCP:
codex mcp add playwright npx "@playwright/mcp@latest"Alternativamente, crea o edita el archivo de configuración ~/.codex/config.toml y añade:
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]Para más información, consulta la documentación de MCP de Codex.
Usa la CLI de Copilot para añadir interactivamente el servidor Playwright MCP:
/mcp addAlternativamente, crea o edita el archivo de configuración ~/.copilot/mcp-config.json y añade:
{
"mcpServers": {
"playwright": {
"type": "local",
"command": "npx",
"tools": [
"*"
],
"args": [
"@playwright/mcp@latest"
]
}
}
}Para más información, consulta la documentación de la CLI de Copilot.
Ve a Cursor Settings -> MCP -> Add new MCP Server. Ponle un nombre a tu gusto, usa el tipo command con el comando npx @playwright/mcp@latest. También puedes verificar la configuración o añadir argumentos como comando haciendo clic en Edit.
Usa la CLI de Factory para añadir el servidor Playwright MCP:
droid mcp add playwright "npx @playwright/mcp@latest"Alternativamente, escribe /mcp dentro del droid de Factory para abrir una interfaz interactiva para gestionar servidores MCP.
Para más información, consulta la documentación de MCP de Factory.
Sigue la guía de instalación de MCP, usa la configuración estándar anterior.
Ve a Advanced settings -> Extensions -> Add custom extension. Ponle un nombre a tu gusto, usa el tipo STDIO, y establece el command a npx @playwright/mcp. Haz clic en "Add Extension".
Usa la CLI de Grok para añadir el servidor Playwright MCP:
grok mcp add playwright -- npx @playwright/mcp@latestAlternativamente, crea o edita el archivo de configuración ~/.grok/config.toml y añade:
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]Para más información, consulta la documentación de MCP de Grok.
Para añadir el servidor Playwright MCP en Junie CLI:
Escribe /mcp
Presiona Ctrl+A para añadir un nuevo servidor MCP
Selecciona Playwright de la lista
Alternativamente, añade a .junie/mcp/mcp.json:
{
"mcpServers": {
"Playwright": {
"command": "npx",
"args": [
"-y",
"@playwright/mcp@latest"
]
}
}
}Para más información, consulta la documentación de configuración de MCP de Junie.
Sigue la documentación de Servidores MCP. Por ejemplo, en .kiro/settings/mcp.json:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
Ve a Program en la barra lateral derecha -> Install -> Edit mcp.json. Usa la configuración estándar anterior.
Sigue la documentación de Servidores MCP. Por ejemplo, en ~/.config/opencode/opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"playwright": {
"type": "local",
"command": [
"npx",
"@playwright/mcp@latest"
],
"enabled": true
}
}
}
Abre el panel de chat de Qodo Gen en VSCode o IntelliJ → Conectar más herramientas → + Añadir nuevo MCP → Pega la configuración estándar anterior.
Haz clic en Save.
Sigue la guía de instalación de MCP, usa la configuración estándar anterior. También puedes instalar el servidor Playwright MCP usando la CLI de VS Code:
# For VS Code
code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'Después de la instalación, el servidor Playwright MCP estará disponible para usar con tu agente de GitHub Copilot en VS Code.
Ve a Settings -> AI -> Manage MCP Servers -> + Add para añadir un servidor MCP. Usa la configuración estándar anterior.
Alternativamente, usa el comando de barra /add-mcp en el prompt de Warp y pega la configuración estándar de arriba:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Sigue la documentación de MCP de Windsurf. Usa la configuración estándar anterior.
El servidor Playwright MCP soporta los siguientes argumentos. Se pueden proporcionar en la configuración JSON anterior, como parte de la lista "args":
Option | Description |
--allowed-hosts <hosts...> | lista separada por comas de hosts desde los que este servidor puede servir. Por defecto, el host al que está vinculado el servidor. Pase '*' para deshabilitar la comprobación de host.env |
--allowed-origins | lista separada por punto y coma de orígenes CONFIABLES que el navegador puede solicitar. Por defecto se permiten todos. Importante: no sirve como límite de seguridad y no afecta las redirecciones.env |
--allow-unrestricted-file-access | permite el acceso a archivos fuera de las raíces del espacio de trabajo. También permite el acceso sin restricciones a URLs file://. Por defecto, el acceso al sistema de archivos está restringido solo a los directorios raíz del espacio de trabajo (o al directorio de trabajo actual si no se configuran raíces), y la navegación a URLs file:// está bloqueada.env |
--blocked-origins | lista separada por punto y coma de orígenes que el navegador no debe solicitar. La lista de bloqueo se evalúa antes que la lista de permitidos. Si se usa sin la lista de permitidos, las solicitudes que no coincidan con la lista de bloqueo aún se permiten. Importante: no sirve como límite de seguridad y no afecta las redirecciones.env |
--block-service-workers | bloquear los service workersenv |
--browser | navegador o canal de Chrome a usar, valores posibles: chrome, firefox, webkit, msedge.env |
--caps | lista separada por comas de capacidades adicionales a habilitar, valores posibles: vision, pdf, devtools.env |
--cdp-endpoint | punto de conexión CDP al que conectarse.env |
--cdp-header <headers...> | encabezados CDP para enviar con la solicitud de conexión, se pueden especificar varios.env |
--cdp-timeout | tiempo de espera en milisegundos para conectarse al punto de conexión CDP, por defecto 30000msenv |
--codegen | especificar el idioma a usar para la generación de código, valores posibles: "typescript", "python", "java", "csharp", "none". Por defecto es "typescript".env |
--config | ruta al archivo de configuración.env |
--console-level | nivel de mensajes de consola a devolver: "error", "warning", "info", "debug". Cada nivel incluye los mensajes de niveles más graves.env |
--device | dispositivo a emular, por ejemplo: "iPhone 15"env |
--mobile | emular un dispositivo móvil genérico (Pixel 10 para Chromium, iPhone 17 para WebKit). Las páginas móviles suelen ser más ligeras, lo que ahorra tokens. No se puede combinar con --device.env |
--executable-path | ruta al ejecutable del navegador.env |
--extension | Conectarse a una instancia de navegador en ejecución (solo Edge/Chrome). Requiere que la "Playwright Extension" esté instalada.env |
--endpoint | Punto de conexión del navegador vinculado al que conectarse.env |
--grant-permissions <permissions...> | Lista de permisos a otorgar al contexto del navegador, por ejemplo "geolocation", "clipboard-read", "clipboard-write".env |
--headless | ejecutar el navegador en modo sin cabeza, con interfaz por defectoenv |
--host | host al que vincular el servidor. Por defecto es localhost. Use 0.0.0.0 para vincular a todas las interfaces.env |
--ignore-https-errors | ignorar errores HTTPSenv |
--init-page <path...> | ruta al archivo TypeScript a evaluar en el objeto page de Playwrightenv |
--init-script <path...> | ruta al archivo JavaScript para agregar como script de inicialización. El script se evaluará en cada página antes de cualquier script de la página. Se puede especificar varias veces.env |
--isolated | mantener el perfil del navegador en memoria, no guardarlo en disco.env |
--image-responses | si se deben enviar respuestas de imágenes al cliente. Puede ser "allow" u "omit". Por defecto es "allow".env |
--no-sandbox | deshabilitar el sandbox para todos los tipos de procesos que normalmente están en sandbox.env |
--output-dir | ruta al directorio para archivos de salida.env |
--output-max-size | Umbral para eliminar archivos de salida antiguos, en bytes.env |
--port | puerto para escuchar en el transporte SSE.env |
--proxy-bypass | dominios separados por comas para omitir el proxy, por ejemplo ".com,chromium.org,.domain.com"env |
--proxy-server | especificar servidor proxy, por ejemplo "http://myproxy:3128" o "socks5://myproxy:8080"env |
--sandbox | habilitar el sandbox para todos los tipos de procesos que normalmente no están en sandbox.env |
--save-session | Si se debe guardar la sesión de Playwright MCP en el directorio de salida.env |
--secrets | ruta a un archivo que contiene secretos en el formato dotenvenv |
--shared-browser-context | reutilizar el mismo contexto de navegador entre todos los clientes HTTP conectados.env |
--snapshot-boxes | incluir el cuadro delimitador de cada elemento como [box=x,y,width,height] en las instantáneas. Las coordenadas son relativas al viewport, en píxeles CSS.env |
--snapshot-mode | al tomar instantáneas para respuestas, especifica el modo a usar. Puede ser "full" o "none". Por defecto es "full".env |
--storage-state | ruta al archivo de estado de almacenamiento para sesiones aisladas.env |
--test-id-attribute | especificar el atributo a usar para los identificadores de prueba, por defecto "data-testid"env |
--timeout-action | especificar el tiempo de espera de acción en milisegundos, por defecto 5000msenv |
--timeout-navigation | especificar el tiempo de espera de navegación en milisegundos, por defecto 60000msenv |
--timeout-settle | cuánto tiempo esperar después de cada acción para que el trabajo desencadenado se estabilice, en milisegundos, por defecto 500msenv |
--user-agent | especificar la cadena de user agentenv |
--user-data-dir | ruta al directorio de datos de usuario. Si no se especifica, se creará un directorio temporal.env |
--viewport-size | especificar el tamaño del viewport del navegador en píxeles, por ejemplo "1280x720"env |
Puede ejecutar Playwright MCP con un perfil persistente como un navegador normal (por defecto), en contextos aislados para sesiones de prueba, o conectarse a su navegador existente mediante la extensión del navegador.
Perfil persistente
Toda la información de inicio de sesión se almacenará en el perfil persistente; puede eliminarlo entre sesiones si desea borrar el estado sin conexión.
El perfil persistente se encuentra en las siguientes ubicaciones y puede anularlo con el argumento --user-data-dir.
# Windows
%USERPROFILE%\AppData\Local\ms-playwright\mcp-{channel}-{workspace-hash}
# macOS
- ~/Library/Caches/ms-playwright/mcp-{channel}-{workspace-hash}
# Linux
- ~/.cache/ms-playwright/mcp-{channel}-{workspace-hash}{workspace-hash} se deriva de la raíz del espacio de trabajo del cliente MCP, por lo que diferentes proyectos obtienen perfiles separados automáticamente.
[!IMPORTANTE] Un perfil persistente solo puede ser utilizado por una instancia de navegador a la vez, por lo que los clientes MCP concurrentes que compartan el mismo espacio de trabajo entrarán en conflicto. Para ejecutar varios clientes en paralelo, inicie cada cliente adicional con
--isolatedo apúntelo a un--user-data-dirdistinto.
Aislado
En el modo aislado, cada sesión se inicia en el perfil aislado. Cada vez que le pide a MCP que cierre el navegador, la sesión se cierra y todo el estado de almacenamiento de esta sesión se pierde. Puede proporcionar un estado de almacenamiento inicial al navegador a través de contextOptions de la configuración o mediante el argumento --storage-state. Obtenga más información sobre el estado de almacenamiento aquí.
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--isolated",
"--storage-state={path/to/storage.json}"
]
}
}
}Extensión del navegador
La extensión de Chrome de Playwright MCP le permite conectarse a pestañas existentes del navegador y aprovechar sus sesiones iniciadas y el estado del navegador. Consulte microsoft/playwright › packages/extension para obtener instrucciones de instalación y configuración.
Hay varias formas de proporcionar el estado inicial al contexto del navegador o a una página.
Para el estado de almacenamiento, puede:
Iniciar con un directorio de datos de usuario usando el argumento --user-data-dir. Esto persistirá todos los datos del navegador entre las sesiones.
Iniciar con un archivo de estado de almacenamiento usando el argumento --storage-state. Esto cargará cookies y almacenamiento local desde el archivo en un contexto de navegador aislado.
Para el estado de la página, puede usar:
--init-page para apuntar a un archivo TypeScript que se evaluará en el objeto de página de Playwright. Esto le permite ejecutar código arbitrario para configurar la página.
// init-page.ts
export default async ({ page }) => {
await page.context().grantPermissions(['geolocation']);
await page.context().setGeolocation({ latitude: 37.7749, longitude: -122.4194 });
await page.setViewportSize({ width: 1280, height: 720 });
};--init-script para apuntar a un archivo JavaScript que se agregará como script de inicialización. El script se evaluará en cada página antes de cualquier script de la página. Esto es útil para anular las API del navegador o configurar el entorno.
// init-script.js
window.isPlaywrightMCP = true;El servidor Playwright MCP se puede configurar usando un archivo de configuración JSON. Puede especificar el archivo de configuración usando la opción de línea de comandos --config:
npx @playwright/mcp@latest --config path/to/config.json{
/**
* The browser to use.
*/
browser?: {
/**
* The type of browser to use.
*/
browserName?: 'chromium' | 'firefox' | 'webkit';
/**
* Keep the browser profile in memory, do not save it to disk.
*/
isolated?: boolean;
/**
* Path to a user data directory for browser profile persistence.
* Temporary directory is created by default.
*/
userDataDir?: string;
/**
* Launch options passed to
* @see https://playwright.dev/docs/api/class-browsertype#browser-type-launch-persistent-context
*
* This is useful for settings options like `channel`, `headless`, `executablePath`, etc.
*/
launchOptions?: playwright.LaunchOptions;
/**
* Context options for the browser context.
*
* This is useful for settings options like `viewport`.
*/
contextOptions?: playwright.BrowserContextOptions;
/**
* Chrome DevTools Protocol endpoint to connect to an existing browser instance in case of Chromium family browsers.
*/
cdpEndpoint?: string;
/**
* CDP headers to send with the connect request.
*/
cdpHeaders?: Record<string, string>;
/**
* Timeout in milliseconds for connecting to CDP endpoint. Defaults to 30000 (30 seconds). Pass 0 to disable timeout.
*/
cdpTimeout?: number;
/**
* Remote endpoint to connect to an existing Playwright server. May be a
* WebSocket URL string, or a [ConnectOptions] object that mirrors the
* `connectOptions` shape used by the test runner. When passed as an object,
* `exposeNetwork`, `headers`, `slowMo`, and `timeout` are forwarded to the
* underlying connect call.
*/
remoteEndpoint?: string | playwright.ConnectOptions & { endpoint: string };
/**
* Paths to TypeScript files to add as initialization scripts for Playwright page.
*/
initPage?: string[];
/**
* Paths to JavaScript files to add as initialization scripts.
* The scripts will be evaluated in every page before any of the page's scripts.
*/
initScript?: string[];
},
/**
* Connect to a running browser instance (Edge/Chrome only). If specified, `browser`
* config is ignored.
* Requires the "Playwright Extension" to be installed.
*/
extension?: boolean;
server?: {
/**
* The port to listen on for SSE or MCP transport.
*/
port?: number;
/**
* The host to bind the server to. Default is localhost. Use 0.0.0.0 to bind to all interfaces.
*/
host?: string;
/**
* The hosts this server is allowed to serve from. Defaults to the host server is bound to.
* This is not for CORS, but rather for the DNS rebinding protection.
*/
allowedHosts?: string[];
},
/**
* List of enabled tool capabilities. Possible values:
* - 'core': Core browser automation features.
* - 'pdf': PDF generation and manipulation.
* - 'vision': Coordinate-based interactions.
* - 'devtools': Developer tools features.
*/
capabilities?: ToolCapability[];
/**
* Whether to save the Playwright session into the output directory.
*/
saveSession?: boolean;
/**
* Reuse the same browser context between all connected HTTP clients.
*/
sharedBrowserContext?: boolean;
/**
* Secrets are used to replace matching plain text in the tool responses to prevent the LLM
* from accidentally getting sensitive data. It is a convenience and not a security feature,
* make sure to always examine information coming in and from the tool on the client.
*/
secrets?: Record<string, string>;
/**
* The directory to save output files.
*/
outputDir?: string;
/**
* Threshold for evicting old output files, in bytes.
*/
outputMaxSize?: number;
console?: {
/**
* The level of console messages to return. Each level includes the messages of more severe levels. Defaults to "info".
*/
level?: 'error' | 'warning' | 'info' | 'debug';
},
network?: {
/**
* List of origins to allow the browser to request. Default is to allow all. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
allowedOrigins?: string[];
/**
* List of origins to block the browser to request. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
blockedOrigins?: string[];
};
/**
* Specify the attribute to use for test ids, defaults to "data-testid".
*/
testIdAttribute?: string;
timeouts?: {
/*
* Configures default action timeout: https://playwright.dev/docs/api/class-page#page-set-default-timeout. Defaults to 5000ms.
*/
action?: number;
/*
* Configures default navigation timeout: https://playwright.dev/docs/api/class-page#page-set-default-navigation-timeout. Defaults to 60000ms.
*/
navigation?: number;
/**
* Configures default expect timeout: https://playwright.dev/docs/test-timeouts#expect-timeout. Defaults to 5000ms.
*/
expect?: number;
/**
* How long to wait after each action for triggered work (navigations, requests) to settle before responding. Defaults to 500ms.
*/
settle?: number;
};
/**
* Whether to send image responses to the client. Can be "allow", "omit", or "auto". Defaults to "auto", which sends images if the client can display them.
*/
imageResponses?: 'allow' | 'omit';
snapshot?: {
/**
* When taking snapshots for responses, specifies the mode to use.
*/
mode?: 'full' | 'none';
/**
* Whether to include each element's bounding box as [box=x,y,width,height] in snapshots.
* Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect).
*/
boxes?: boolean;
};
/**
* allowUnrestrictedFileAccess acts as a guardrail to prevent the LLM from accidentally
* wandering outside its intended workspace. It is a convenience defense to catch unintended
* file access, not a secure boundary; a deliberate attempt to reach other directories can be
* easily worked around, so always rely on client-level permissions for true security.
*/
allowUnrestrictedFileAccess?: boolean;
/**
* Specify the language to use for code generation.
*/
codegen?: 'typescript' | 'python' | 'java' | 'csharp' | 'none';
}Al ejecutar un navegador con interfaz gráfica en un sistema sin pantalla o desde procesos de trabajo de los IDE, ejecute el servidor MCP desde un entorno con DISPLAY y pase la bandera --port para habilitar el transporte HTTP.
npx @playwright/mcp@latest --port 8931Y luego en la configuración del cliente MCP, establezca la url en el punto final HTTP:
{
"mcpServers": {
"playwright": {
"url": "http://localhost:8931/mcp"
}
}
}Related MCP server: Playwright MCP Server
Playwright MCP no es un límite de seguridad. Consulte Prácticas recomendadas de seguridad de MCP para obtener orientación sobre cómo asegurar su implementación.
NOTA: La implementación de Docker solo admite chromium sin cabeza por el momento.
{
"mcpServers": {
"playwright": {
"command": "docker",
"args": ["run", "-i", "--rm", "--init", "--pull=always", "mcr.microsoft.com/playwright/mcp"]
}
}
}O si prefiere ejecutar el contenedor como un servicio de larga duración en lugar de dejar que el cliente MCP lo genere, use:
docker run -d -i --rm --init --pull=always \
--entrypoint node \
--name playwright \
-p 8931:8931 \
mcr.microsoft.com/playwright/mcp \
/app/cli.js --headless --browser chromium --no-sandbox --port 8931 --host 0.0.0.0El servidor escuchará en el puerto 8931 del host y cualquier cliente MCP podrá acceder a él.
Puede construir la imagen de Docker usted mismo.
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);
// ...
});browser_click
Título: Hacer clic
Descripción: Realizar un clic en una página web
Parámetros:
element (string, opcional): Descripción legible del elemento utilizada para obtener permiso para interactuar con el elemento
target (string): Referencia exacta del elemento objetivo de la instantánea de la página, o un selector de elemento único
doubleClick (boolean, opcional): Si se debe realizar un doble clic en lugar de un solo clic
button (string, opcional): Botón para hacer clic, por defecto izquierdo
modifiers (array, opcional): Teclas modificadoras a presionar
Solo lectura: false
browser_close
Título: Cerrar navegador
Descripción: Cerrar la página
Parámetros: Ninguno
Solo lectura: false
browser_console_messages
Título: Obtener mensajes de consola
Descripción: Devuelve todos los mensajes de consola
Parámetros:
level (string): Nivel de los mensajes de consola a devolver. Cada nivel incluye los mensajes de niveles más severos. Por defecto "info".
all (boolean, opcional): Devuelve todos los mensajes de consola desde el inicio de la sesión, no solo desde la última navegación. Por defecto false.
filename (string, opcional): Nombre de archivo para guardar los mensajes de consola. Si no se proporciona, los mensajes se devuelven como texto.
Solo lectura: true
browser_drag
Título: Arrastrar mouse
Descripción: Realizar arrastrar y soltar entre dos elementos
Parámetros:
startElement (string, opcional): Descripción legible del elemento de origen utilizada para obtener permiso para interactuar con el elemento
startTarget (string): Referencia exacta del elemento objetivo de la instantánea de la página, o un selector de elemento único
endElement (string, opcional): Descripción legible del elemento de destino utilizada para obtener permiso para interactuar con el elemento
endTarget (string): Referencia exacta del elemento objetivo de la instantánea de la página, o un selector de elemento único
Solo lectura: false
browser_drop
Título: Soltar archivos o datos sobre un elemento
Descripción: Suelta archivos o datos con tipo MIME sobre un elemento, como si se arrastraran desde fuera de la página. Se debe proporcionar al menos uno de "paths" o "data".
Parámetros:
element (string, opcional): Descripción legible del elemento utilizada para obtener permiso para interactuar con el elemento
target (string): Referencia exacta del elemento objetivo de la instantánea de la página, o un selector de elemento único
paths (array, opcional): Rutas absolutas a los archivos para soltar sobre el elemento.
data (object, opcional): Datos a soltar, como un mapa de tipo MIME a valor de cadena (por ejemplo, {"text/plain": "hello", "text/uri-list": "https://example.com"}).
Solo lectura: false
browser_evaluate
Título: Evaluar JavaScript
Descripción: Evaluar expresión JavaScript en la página o elemento
Parámetros:
element (string, opcional): Descripción legible del elemento utilizada para obtener permiso para interactuar con el elemento
target (string, opcional): Referencia exacta del elemento objetivo de la instantánea de la página, o un selector de elemento único
function (string): () => { /* código / } o (element) => { / código */ } cuando se proporciona elemento
filename (string, opcional): Nombre de archivo para guardar el resultado. Si no se proporciona, el resultado se devuelve como texto.
Solo lectura: false
browser_file_upload
Título: Subir archivos
Descripción: Subir uno o varios archivos
Parámetros:
paths (array, opcional): Las rutas absolutas a los archivos a subir. Puede ser un solo archivo o varios archivos. Si se omite, se cancela el selector de archivos.
Solo lectura: false
browser_fill_form
Título: Rellenar formulario
Descripción: Rellenar múltiples campos de formulario
Parámetros:
fields (array): Campos a rellenar
Solo lectura: false
browser_find
Título: Buscar en instantánea de página
Descripción: Busca en la instantánea de accesibilidad de la página actual texto o una expresión regular. Devuelve nodos de instantánea coincidentes con algunas líneas de contexto circundante (como fragmentos de búsqueda), cada uno mostrado bajo su ruta desde la raíz del árbol, lo cual es más económico que capturar toda la instantánea cuando solo necesita localizar un elemento y su referencia.
Parámetros:
text (string, opcional): Texto plano para buscar en la instantánea de la página (coincidencia de subcadena sin distinción de mayúsculas/minúsculas). Proporcione texto o regex, no ambos.
regex (string, opcional): Expresión regular para buscar en la instantánea de la página. La coincidencia distingue mayúsculas/minúsculas por defecto; envuelva el patrón entre barras para agregar banderas, por ejemplo, "/error/i" para no distinguir mayúsculas/minúsculas. Proporcione texto o regex, no ambos.
Solo lectura: true
browser_handle_dialog
Título: Manejar un diálogo
Descripción: Manejar un diálogo
Parámetros:
accept (boolean): Si se debe aceptar el diálogo.
promptText (string, opcional): El texto del aviso en caso de un diálogo de aviso.
Solo lectura: false
browser_hover
Título: Pasar el mouse por encima
Descripción: Pasar el mouse sobre un elemento en la página
Parámetros:
element (string, opcional): Descripción legible del elemento utilizada para obtener permiso para interactuar con el elemento
target (string): Referencia exacta del elemento objetivo de la instantánea de la página, o un selector de elemento único
Solo lectura: false
browser_navigate
Título: Navegar a una URL
Descripción: Navegar a una URL
Parámetros:
url (string): La URL a la que navegar
Solo lectura: false
browser_navigate_back
Título: Volver atrás
Descripción: Volver a la página anterior en el historial
Parámetros: Ninguno
Solo lectura: false
browser_network_request
Título: Mostrar detalles de solicitud de red
Descripción: Devuelve los detalles completos (encabezados y cuerpo) de una sola solicitud de red, o una sola parte si se establece part. Use el número de browser_network_requests.
Parámetros:
index (integer): Índice basado en 1 de la solicitud, como se imprime en browser_network_requests.
part (string, opcional): Devuelve solo esta parte de la solicitud. Omita para devolver los detalles completos.
filename (string, opcional): Nombre de archivo para guardar el resultado. Si no se proporciona, la salida se devuelve como texto.
Solo lectura: true
browser_network_requests
Título: Listar solicitudes de red
Descripción: Devuelve una lista numerada de solicitudes de red desde la carga de la página. Use browser_network_request con el número para obtener los detalles completos.
Parámetros:
static (boolean): Si se deben incluir recursos estáticos exitosos como imágenes, fuentes, scripts, etc. Por defecto false.
filter (string, opcional): Solo devolver solicitudes cuya URL coincida con esta expresión regular (por ejemplo, "/api/.*user").
filename (string, opcional): Nombre de archivo para guardar las solicitudes de red. Si no se proporciona, las solicitudes se devuelven como texto.
Solo lectura: true
browser_press_key
Título: Presionar una tecla
Descripción: Presionar una tecla en el teclado
Parámetros:
key (string): Nombre de la tecla a presionar o un carácter a generar, como ArrowLeft o a
Solo lectura: false
browser_resize
Título: Redimensionar ventana del navegador
Descripción: Redimensionar la ventana del navegador
Parámetros:
width (number): Ancho de la ventana del navegador
height (number): Alto de la ventana del navegador
Solo lectura: false
browser_run_code_unsafe
Título: Ejecutar código de Playwright (no seguro)
Descripción: Ejecutar un fragmento de código de Playwright. No seguro: ejecuta JavaScript arbitrario en el proceso del servidor de Playwright y es equivalente a RCE.
Parámetros:
code (string, opcional): Una función de JavaScript que contiene código de Playwright para ejecutar. Se invocará con un solo argumento, page, que puede usar para cualquier interacción con la página. Por ejemplo: async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }
filename (string, opcional): Cargar código desde el archivo especificado. Si se proporcionan tanto code como filename, se ignorará code.
Solo lectura: false
browser_select_option
Título: Seleccionar opción
Descripción: Seleccionar una opción en un menú desplegable
Parámetros:
element (string, opcional): Descripción del elemento legible para humanos utilizada para obtener permiso para interactuar con el elemento
target (string): Referencia exacta del elemento objetivo desde la instantánea de la página, o un selector de elemento único
values (array): Arreglo de valores a seleccionar en el menú desplegable. Puede ser un solo valor o múltiples valores.
Solo lectura: false
browser_snapshot
Título: Instantánea de página
Descripción: Capturar una instantánea de accesibilidad de la página actual, esto es mejor que una captura de pantalla
Parámetros:
target (string, opcional): Referencia exacta del elemento objetivo desde la instantánea de la página, o un selector de elemento único
filename (string, opcional): Guardar la instantánea en un archivo markdown en lugar de devolverla en la respuesta.
depth (number, opcional): Limitar la profundidad del árbol de instantáneas
boxes (boolean, opcional): Incluir el cuadro delimitador de cada elemento como [box=x,y,width,height] en la instantánea. Las coordenadas son relativas a la ventana gráfica, en píxeles CSS (Element.getBoundingClientRect)
Solo lectura: true
browser_take_screenshot
Título: Tomar una captura de pantalla
Descripción: Tomar una captura de pantalla de la página actual. No puede realizar acciones basadas en la captura de pantalla, use browser_snapshot para acciones.
Parámetros:
element (string, opcional): Descripción del elemento legible para humanos utilizada para obtener permiso para interactuar con el elemento
target (string, opcional): Referencia exacta del elemento objetivo desde la instantánea de la página, o un selector de elemento único
type (string, opcional): Formato de imagen para la captura de pantalla. Si no se especifica, se infiere de la extensión del archivo, de lo contrario png.
filename (string, opcional): Nombre de archivo para guardar la captura de pantalla. Por defecto es page-{timestamp}.{png|jpeg|webp} si no se especifica. Prefiera nombres de archivo relativos para permanecer dentro del directorio de salida.
fullPage (boolean, opcional): Cuando es verdadero, toma una captura de pantalla de la página completa desplazable, en lugar de la ventana gráfica visible actualmente. No se puede usar con capturas de pantalla de elementos.
scale (string): Escala de resolución de imagen. "css" produce una captura de pantalla dimensionada en píxeles CSS (más pequeña, consistente entre dispositivos). "device" produce una captura de pantalla de alta resolución usando píxeles del dispositivo (más grande, tiene en cuenta la relación de píxeles del dispositivo). El valor predeterminado es css.
Solo lectura: true
browser_type
Título: Escribir texto
Descripción: Escribir texto en un elemento editable
Parámetros:
element (string, opcional): Descripción del elemento legible para humanos utilizada para obtener permiso para interactuar con el elemento
target (string): Referencia exacta del elemento objetivo desde la instantánea de la página, o un selector de elemento único
text (string): Texto a escribir en el elemento
submit (boolean, opcional): Si se debe enviar el texto ingresado (presionar Enter después)
slowly (boolean, opcional): Si se debe escribir un carácter a la vez. Útil para activar manejadores de teclas en la página. Por defecto, todo el texto se ingresa de una vez.
Solo lectura: false
browser_wait_for
Título: Esperar
Descripción: Esperar a que aparezca o desaparezca un texto, o que transcurra un tiempo especificado
Parámetros:
time (number, opcional): El tiempo a esperar en segundos
text (string, opcional): El texto a esperar
textGone (string, opcional): El texto a esperar que desaparezca
Solo lectura: false
browser_tabs
Título: Gestionar pestañas
Descripción: Listar, crear, cerrar o seleccionar una pestaña del navegador.
Parámetros:
action (string): Operación a realizar
index (number, opcional): Índice de pestaña, utilizado para cerrar/seleccionar. Si se omite para cerrar, se cierra la pestaña actual.
url (string, opcional): URL a navegar en la nueva pestaña, utilizado para nueva.
Solo lectura: false
browser_get_config
Título: Obtener configuración
Descripción: Obtener la configuración resuelta final después de fusionar opciones de línea de comandos, variables de entorno y archivo de configuración.
Parámetros: Ninguno
Solo lectura: true
browser_network_state_set
Título: Establecer estado de red
Descripción: Establece el estado de red del navegador en línea o fuera de línea. Cuando está fuera de línea, todas las solicitudes de red fallarán.
Parámetros:
state (string): Establecer en "offline" para simular modo fuera de línea, "online" para restaurar la conectividad de red
Solo lectura: false
browser_route
Título: Simular solicitudes de red
Descripción: Configurar una ruta para simular solicitudes de red que coincidan con un patrón de URL
Parámetros:
pattern (string): Patrón de URL a coincidir (ej., "/api/users", "/*.{png,jpg}")
status (number, opcional): Código de estado HTTP a devolver (por defecto: 200)
body (string, opcional): Cuerpo de la respuesta (texto o cadena JSON)
contentType (string, opcional): Encabezado Content-Type (ej., "application/json", "text/html")
headers (array, opcional): Encabezados a agregar en formato "Nombre: Valor"
removeHeaders (string, opcional): Lista separada por comas de nombres de encabezados a eliminar de la solicitud
Solo lectura: false
browser_route_list
Título: Listar rutas de red
Descripción: Listar todas las rutas de red activas
Parámetros: Ninguno
Solo lectura: true
browser_unroute
Título: Eliminar rutas de red
Descripción: Eliminar rutas de red que coincidan con un patrón (o todas las rutas si no se especifica ningún patrón)
Parámetros:
pattern (string, opcional): Patrón de URL a desrutar (omitir para eliminar todas las rutas)
Solo lectura: false
browser_cookie_clear
Título: Limpiar cookies
Descripción: Limpiar todas las cookies
Parámetros: Ninguno
Solo lectura: false
browser_cookie_delete
Título: Eliminar cookie
Descripción: Eliminar una cookie específica
Parámetros:
name (string): Nombre de la cookie a eliminar
Solo lectura: false
browser_cookie_get
Título: Obtener cookie
Descripción: Obtener una cookie específica por nombre
Parámetros:
name (string): Nombre de la cookie a obtener
Solo lectura: true
browser_cookie_list
Título: Listar cookies
Descripción: Listar todas las cookies (opcionalmente filtradas por dominio/ruta)
Parámetros:
domain (string, opcional): Filtrar cookies por dominio
path (string, opcional): Filtrar cookies por ruta
Solo lectura: true
browser_cookie_set
Título: Establecer cookie
Descripción: Establecer una cookie con banderas opcionales (domain, path, expires, httpOnly, secure, sameSite)
Parámetros:
name (string): Nombre de la cookie
value (string): Valor de la cookie
domain (string, opcional): Dominio de la cookie
path (string, opcional): Ruta de la cookie
expires (number, opcional): Expiración de la cookie como marca de tiempo Unix
httpOnly (boolean, opcional): Si la cookie es solo HTTP
secure (boolean, opcional): Si la cookie es segura
sameSite (string, opcional): Atributo SameSite de la cookie
Solo lectura: false
browser_localstorage_clear
Título: Limpiar localStorage
Descripción: Limpiar todo localStorage
Parámetros: Ninguno
Solo lectura: false
browser_localstorage_delete
Título: Eliminar elemento de localStorage
Descripción: Eliminar un elemento de localStorage
Parámetros:
key (string): Clave a eliminar
Solo lectura: false
browser_localstorage_get
Título: Obtener elemento de localStorage
Descripción: Obtener un elemento de localStorage por clave
Parámetros:
key (string): Clave a obtener
Solo lectura: true
browser_localstorage_list
Título: Listar localStorage
Descripción: Listar todos los pares clave-valor de localStorage
Parámetros: Ninguno
Solo lectura: true
browser_localstorage_set
Título: Establecer elemento de localStorage
Descripción: Establecer un elemento de localStorage
Parámetros:
key (string): Clave a establecer
value (string): Valor a establecer
Solo lectura: false
browser_sessionstorage_clear
Título: Limpiar sessionStorage
Descripción: Limpiar todo sessionStorage
Parámetros: Ninguno
Solo lectura: false
browser_sessionstorage_delete
Título: Eliminar elemento de sessionStorage
Descripción: Eliminar un elemento de sessionStorage
Parámetros:
key (string): Clave a eliminar
Solo lectura: false
browser_sessionstorage_get
Título: Obtener elemento de sessionStorage
Descripción: Obtener un elemento de sessionStorage por clave
Parámetros:
key (string): Clave a obtener
Solo lectura: true
browser_sessionstorage_list
Título: Listar sessionStorage
Descripción: Listar todos los pares clave-valor de sessionStorage
Parámetros: Ninguno
Solo lectura: true
browser_sessionstorage_set
Título: Establecer elemento de sessionStorage
Descripción: Establece un elemento de sessionStorage
Parámetros:
key (cadena): Clave a establecer
value (cadena): Valor a establecer
Solo lectura: false
browser_set_storage_state
Título: Restaurar estado de almacenamiento
Descripción: Restaura el estado de almacenamiento (cookies, almacenamiento local) desde un archivo. Esto borra las cookies y el almacenamiento local existentes antes de restaurar.
Parámetros:
filename (cadena): Ruta al archivo de estado de almacenamiento desde el cual restaurar
Solo lectura: false
browser_storage_state
Título: Guardar estado de almacenamiento
Descripción: Guarda el estado de almacenamiento (cookies, almacenamiento local) en un archivo para su reutilización posterior
Parámetros:
filename (cadena, opcional): Nombre del archivo para guardar el estado de almacenamiento. Por defecto es storage-state-{timestamp}.json si no se especifica.
Solo lectura: true
browser_annotate
Título: Anotar la página actual
Descripción: Abre el Panel de Playwright en modo de anotación para la página actual y espera a que el usuario dibuje anotaciones. Devuelve la captura de pantalla anotada, la instantánea ARIA y la lista de anotaciones.
Parámetros: Ninguno
Solo lectura: true
browser_hide_highlight
Título: Ocultar resaltado de elemento
Descripción: Elimina una superposición de resaltado añadida previamente para el elemento.
Parámetros:
element (cadena, opcional): Descripción legible del elemento utilizada al añadir el resaltado; debe coincidir con el valor pasado a browser_highlight.
target (cadena, opcional): Referencia exacta del elemento objetivo desde la instantánea de la página, o un selector de elemento único
Solo lectura: true
browser_highlight
Título: Resaltar elemento
Descripción: Muestra una superposición de resaltado persistente alrededor del elemento en la página.
Parámetros:
element (cadena, opcional): Descripción legible del elemento utilizada para obtener permiso para interactuar con el elemento
target (cadena): Referencia exacta del elemento objetivo desde la instantánea de la página, o un selector de elemento único
style (cadena, opcional): CSS en línea adicional aplicado a la superposición de resaltado, por ejemplo "outline: 2px dashed red".
Solo lectura: true
browser_resume
Título: Reanudar ejecución de script pausada
Descripción: Reanuda la ejecución del script después de que se haya pausado. Cuando se llama con step establecido en true, la ejecución se pausará de nuevo antes de la siguiente acción.
Parámetros:
step (booleano, opcional): Cuando es true, la ejecución se pausará de nuevo antes de la siguiente acción, permitiendo la depuración paso a paso.
location (cadena, opcional): Pausar la ejecución en un :<línea> específico, por ejemplo "example.spec.ts:42".
Solo lectura: false
browser_start_tracing
Título: Iniciar trazado
Descripción: Iniciar grabación de trazado
Parámetros: Ninguno
Solo lectura: true
browser_start_video
Título: Iniciar video
Descripción: Iniciar grabación de video
Parámetros:
filename (cadena, opcional): Nombre del archivo para guardar el video.
size (objeto, opcional): Tamaño del video
Solo lectura: true
browser_stop_tracing
Título: Detener trazado
Descripción: Detener grabación de trazado
Parámetros: Ninguno
Solo lectura: true
browser_stop_video
Título: Detener video
Descripción: Detener grabación de video
Parámetros: Ninguno
Solo lectura: true
browser_video_chapter
Título: Capítulo de video
Descripción: Añade un marcador de capítulo a la grabación de video. Muestra una tarjeta de capítulo a pantalla completa con fondo desenfocado.
Parámetros:
title (cadena): Título del capítulo
description (cadena, opcional): Descripción del capítulo
duration (número, opcional): Duración en milisegundos para mostrar la tarjeta del capítulo
Solo lectura: true
browser_video_hide_actions
Título: Ocultar superposiciones de acciones
Descripción: Dejar de anotar las acciones realizadas en la página.
Parámetros: Ninguno
Solo lectura: true
browser_video_show_actions
Título: Mostrar superposiciones de acciones
Descripción: Anota las acciones posteriores realizadas en la página con un cartel que nombra la acción y resalta el elemento objetivo. Útil durante la grabación de video o la transmisión de pantalla.
Parámetros:
duration (número, opcional): Cuánto tiempo permanece cada anotación de acción en pantalla, en milisegundos. Por defecto es 500.
position (cadena, opcional): Dónde colocar el título de la acción en relación con la página. Por defecto es arriba a la derecha.
cursor (cadena, opcional): Decoración del cursor para acciones de puntero. "pointer" (por defecto) anima un puntero de ratón desde el punto de acción anterior al siguiente; "none" desactiva la decoración del cursor.
Solo lectura: true
browser_mouse_click_xy
Título: Hacer clic
Descripción: Hacer clic con el botón del ratón en una posición determinada
Parámetros:
x (número): Coordenada X
y (número): Coordenada Y
button (cadena, opcional): Botón para hacer clic, por defecto es izquierdo
clickCount (número, opcional): Número de clics, por defecto es 1
delay (número, opcional): Tiempo de espera entre presionar y soltar el ratón en milisegundos, por defecto es 0
Solo lectura: false
browser_mouse_down
Título: Presionar ratón hacia abajo
Descripción: Presionar el botón del ratón hacia abajo
Parámetros:
button (cadena, opcional): Botón a presionar, por defecto es izquierdo
Solo lectura: false
browser_mouse_drag_xy
Título: Arrastrar ratón
Descripción: Arrastrar el botón izquierdo del ratón a una posición determinada
Parámetros:
startX (número): Coordenada X de inicio
startY (número): Coordenada Y de inicio
endX (número): Coordenada X de fin
endY (número): Coordenada Y de fin
Solo lectura: false
browser_mouse_move_xy
Título: Mover ratón
Descripción: Mover el ratón a una posición determinada
Parámetros:
x (número): Coordenada X
y (número): Coordenada Y
Solo lectura: false
browser_mouse_up
Título: Soltar ratón
Descripción: Soltar el botón del ratón
Parámetros:
button (cadena, opcional): Botón a soltar, por defecto es izquierdo
Solo lectura: false
browser_mouse_wheel
Título: Desplazar rueda del ratón
Descripción: Desplazar la rueda del ratón
Parámetros:
deltaX (número): Delta X
deltaY (número): Delta Y
Solo lectura: false
browser_pdf_save
Título: Guardar como PDF
Descripción: Guardar página como PDF
Parámetros:
filename (cadena, opcional): Nombre del archivo para guardar el PDF. Por defecto es page-{timestamp}.pdf si no se especifica. Prefiere nombres de archivo relativos para permanecer dentro del directorio de salida.
Solo lectura: true
browser_generate_locator
Título: Crear localizador para elemento
Descripción: Generar localizador para el elemento dado para usar en pruebas
Parámetros:
element (cadena, opcional): Descripción legible del elemento utilizada para obtener permiso para interactuar con el elemento
target (cadena): Referencia exacta del elemento objetivo desde la instantánea de la página, o un selector de elemento único
Solo lectura: true
browser_verify_element_visible
Título: Verificar elemento visible
Descripción: Verificar que el elemento es visible en la página
Parámetros:
role (cadena): ROL del elemento. Se puede encontrar en la instantánea así: - {ROL} "Nombre Accesible":
accessibleName (cadena): NOMBRE_ACCESIBLE del elemento. Se puede encontrar en la instantánea así: - rol "{NOMBRE_ACCESIBLE}"
Solo lectura: false
browser_verify_list_visible
Título: Verificar lista visible
Descripción: Verificar que la lista es visible en la página
Parámetros:
element (cadena): Descripción legible de la lista
target (cadena): Referencia exacta del elemento objetivo que apunta a la lista
items (matriz): Elementos a verificar
Solo lectura: false
browser_verify_text_visible
Título: Verificar texto visible
Descripción: Verificar que el texto es visible en la página. Prefiere browser_verify_element_visible si es posible.
Parámetros:
text (cadena): TEXTO a verificar. Se puede encontrar en la instantánea así: - rol "Nombre Accesible": {TEXTO} o así: - texto: {TEXTO}
Solo lectura: false
browser_verify_value
Título: Verificar valor
Descripción: Verificar el valor del elemento
Parámetros:
type (cadena): Tipo del elemento
element (cadena): Descripción legible del elemento
target (cadena): Referencia exacta del elemento objetivo desde la instantánea de la página
value (cadena): Valor a verificar. Para casilla de verificación, usa "true" o "false".
Solo lectura: false
Perform click on a web page
| Name | Required | Description | Default |
|---|---|---|---|
| button | No | Button to click, defaults to left | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| modifiers | No | Modifier keys to press | |
| doubleClick | No | Whether to perform a double click instead of a single click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating the tool mutates state and can be destructive. The description adds no further behavioral disclosure, such as possible navigation or permission requirements. It does not contradict annotations, but provides no value beyond 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 concise sentence with no filler. However, it is terse and omits useful context that could be added without bloat, such as the requirement for a snapshot target. It is appropriately sized but not front-loaded with any distinguishing 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 moderate complexity (5 parameters, no output schema), the description alone is minimally sufficient because the schema fully describes parameters. However, it lacks context about return values, when to use click vs other actions, and potential side effects. The schema covers parameter semantics, so a score of 3 is appropriate.
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 every parameter documented (e.g., target is 'Exact target element reference from the page snapshot, or a unique element selector'). The description itself adds no additional parameter meaning, so the baseline of 3 applies.
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 click') and the resource ('web page'), which is specific enough. However, it does not differentiate from sibling interaction tools like browser_hover or browser_drag; the agent must infer that 'click' is a distinct action without additional context. It is unambiguous about the core operation but lacks detail on the target element requirement.
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 does not mention prerequisites such as needing a page snapshot to obtain a valid target, nor does it contrast with browser_hover or browser_drag. An agent receives no 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.
Close the page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already indicates destructiveHint=true, so the agent knows the action is destructive. The description simply repeats that by saying 'close' without adding any extra context about side effects (e.g., whether it closes just the current tab, loses unsaved state, or affects other tabs). It does not contradict the annotation, but it adds no new behavioral information.
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, using only three words. It communicates the essential action and target without any fluff, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is functional but lacks completeness. It leaves open the scope of 'close'—does it close the current page/tab, or the entire browser? In a context with sibling tools like browser_tabs, this ambiguity could be problematic. More detail would improve it.
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 are no parameters, so the schema coverage is trivially complete at 100%. The description does not need to explain any parameter semantics, and the baseline score of 3 applies.
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 the resource (page), making it unambiguous. It is distinct from sibling tools like browser_navigate or browser_snapshot, so an agent can easily identify it.
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 does not mention potential alternatives (e.g., using browser_tabs to manage multiple pages) or any conditions that would make closing appropriate. The context is minimal and leaves the decision entirely to the agent.
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 |
|---|---|---|---|
| all | No | Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false. | |
| level | Yes | Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info". | info |
| filename | No | Filename to save the console messages to. If not provided, messages are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true and destructiveHint false, so the description adds no conflicting side-effect information. It does not elaborate on behavior such as saving to a file, but that is covered by parameter descriptions.
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 no redundancy, front-loading the verb and object.
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 simple read-only tool with full schema coverage, the description is adequate, though it omits explicit use-case guidance and output format details beyond what the schema provides.
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 coverage is 100% with detailed parameter descriptions, so the tool description itself does not add meaning beyond the schema, but no parameter meaning is missing.
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?
Description uses a specific verb 'Returns' and identifies the resource 'console messages' with scope 'all', making the tool's purpose clear and distinct from sibling tools such as network request retrieval.
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 like browser_network_requests or browser_snapshot, nor does it mention filtering or filename-saving 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 |
|---|---|---|---|
| endTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| endElement | No | Human-readable target element description used to obtain the permission to interact with the element | |
| startTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| startElement | No | Human-readable source element description used to obtain the permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds no extra behavioral context such as side effects on the DOM or event firing, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and provides the core information without any irrelevant detail.
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 simple action with well-described parameters and no output schema, the description is mostly complete. It does not mention any return values or wait behavior, but the lack of output schema makes this acceptable. It could have added a note about the order of start and end parameters, but the parameter names and descriptions handle that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all four parameters described. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (perform drag and drop) and the resource (between two elements), distinguishing it from sibling tools like browser_click, browser_hover, and browser_drop. It is specific and unambiguous.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention conditions such as needing to move an element or triggering drag-and-drop events, nor does it reference sibling tools like browser_drop or browser_click.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Data to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}). | |
| paths | No | Absolute paths to files to drop onto the element. | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructive and non-read-only behavior, so the description does not need to repeat that. The description adds useful semantic context about simulating an external drag, but does not disclose any side effects beyond the basic drop action.
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, focused sentence that concisely explains both the action and the key parameter requirement. No filler or redundancy.
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?
The description, combined with the detailed schema and annotations, provides enough information to invoke the tool correctly. There is no output schema, so return-value details are not required, and the parameter permission explanation is handled by the 'element' field description.
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?
All parameters have clear schema descriptions. The tool description adds an important cross-parameter constraint that at least one of 'paths' or 'data' must be provided, which is not otherwise expressed in the 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 action: dropping files or MIME-typed data onto an element. It uses a specific verb and resource, and distinguishes itself from in-page drag operations by specifying 'as if dragged from outside the page'.
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 gives a useful usage constraint ('At least one of paths or data must be provided') and hints at external drag context, but it does not explicitly name sibling tools or state when to prefer this over browser_file_upload or browser_drag.
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 |
|---|---|---|---|
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | Filename to save the result to. If not provided, result is returned as text. | |
| function | Yes | () => { /* code */ } or (element) => { /* code */ } when element is provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, so the agent knows this can modify state. The description adds minimal context beyond that—it mentions 'on page or element' but doesn't warn about the power of arbitrary JS execution or potential side effects. Since the annotation covers the destructive nature, the description's lack of extra detail keeps it at a baseline 3.
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?
A single, clear sentence with no redundant words. The action is front-loaded and easy to parse. This is appropriately concise for a tool whose parameter details are already in the schema.
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 that this tool executes arbitrary JavaScript with destructive potential, the description is too sparse. It doesn't mention that the function can modify the page, that results can be saved to a file (though schema covers it), or that there is a separate unsafe variant (browser_run_code_unsafe) that might be more appropriate for certain tasks. The description lacks the context an agent needs to safely and correctly use this tool, especially when annotations already warn about destructiveness but the description provides no additional 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 all four parameters are documented in the schema itself. The description does not add any meaning beyond what the schema provides—it doesn't elaborate on the function syntax, target usage, or filename behavior. With high schema coverage, the baseline is 3, and the description contributes nothing extra.
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 'Evaluate' and the resource 'JavaScript expression on page or element', making the core purpose obvious. However, it doesn't distinguish from the sibling browser_run_code_unsafe, which might also execute code, so it loses a point for not differentiating between similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like browser_run_code_unsafe or when to avoid it. No context about prerequisites (e.g., page must be loaded) or scenarios that favor this tool over others. The description simply states the action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one or multiple files
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructive behavior and non-read-only semantics, so the description does not need to restate those. However, the description does not mention side effects beyond uploading, such as navigating away, opening or cancelling a file chooser, or potential overwrite behavior, though the parameter description partially covers the cancellation case.
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 and free of filler. Every word contributes meaning, and the parameter description adds necessary details without redundancy.
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 simple one-parameter tool with no output schema, the description and parameter comment cover the essential input and basic behavior. However, it does not describe what happens after the upload, what success or failure looks like, or how this fits into the broader browser automation workflow, leaving some practical context missing.
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 schema only defines an array of strings, but the parameter description adds important meaning: paths must be absolute, multiple files are allowed, and omitting the parameter cancels the file chooser. This goes beyond the raw schema and helps an agent use the parameter correctly.
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 the resource ('files'), and specifies 'one or multiple'. It does not explicitly state the destination or context, but the tool name and sibling set make the browser file-upload intent sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as browser_drop or other browser interaction tools. It also does not mention prerequisites like whether the file chooser must already be open or how paths should be formatted beyond 'absolute'.
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?
The annotations already declare readOnlyHint=false and destructiveHint=true, so the write and potentially destructive nature is covered. The description adds the 'multiple form fields' detail but does not disclose additional behavior such as overwriting values or submitting the form.
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 no redundant words or boilerplate. It is appropriately short and easy to parse, though it sacrifices deeper context for brevity.
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?
The rich schema fully documents the nested field objects, including target references, type-specific value behavior, and permission-related element descriptions. Combined with the read-only and destructive annotations, the description is sufficient for correct invocation; only alternative-selection guidance is missing.
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 coverage is 100%: the fields array and its nested target, name, type, value, and element properties all have descriptive text. The description itself does not add parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields' clearly identifies the action and resource, and the word 'multiple' helps distinguish it from single-field tools like browser_type. It does not explicitly contrast with sibling tools, but the core purpose is unambiguous.
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 for when to use this tool instead of alternatives such as browser_type, browser_select_option, or browser_click. The term 'multiple' implies batch usage, but there is no explicit when-to-use or exclusion context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Plain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both. | |
| regex | No | Regular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds useful behavioral detail about return format, surrounding context, path-from-root presentation, and cost characteristics. It is consistent with the annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, well-structured sentence that front-loads the action and then provides the output shape and the key trade-off. There is no filler or redundancy; every clause earns its place.
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?
The description explains return shape and the main use case, and annotations cover safety. However, since neither parameter is marked required in the schema, the description could more explicitly instruct the agent to provide exactly one of text or regex.
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 coverage is 100%; both text and regex are already documented with mutual exclusivity and regex flag syntax. The description adds no parameter-level meaning beyond restating that either text or regex is used, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('the accessibility snapshot of the current page'), and a well-defined result (matching snapshot nodes with surrounding context and refs). It also distinguishes itself from the whole-snapshot sibling by explaining its narrower focus.
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?
It gives a clear when-to-use condition: this is 'cheaper than capturing the whole snapshot when you only need to locate an element and its ref.' It implicitly contrasts with browser_snapshot but does not explicitly name the sibling or state when NOT to use this tool, so it stops short of full guidance.
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?
The annotations indicate readOnlyHint=false and destructiveHint=true, covering the main safety aspect. However, the description adds no detail about side effects, such as submitting a form or canceling a prompt, beyond what the parameter names imply. It does not clearly disclose the consequences of accepting or rejecting.
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 short and lacks necessary detail, making it under-specified. It is terse but not informative enough to guide an agent effectively, similar to a placeholder like 'Process'.
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?
No output schema or additional context is provided. The description does not explain what happens after handling the dialog, how the parameters interact, or any post-conditions. This is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'accept' (boolean) and 'promptText' (string for prompt dialogs). The description does not add extra meaning, but the schema already provides adequate parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' identifies the action and resource but is vague. It does not specify the type of dialog (alert, confirm, prompt) or the precise effect, though the 'accept' parameter implies accept/dismiss. It is distinct from sibling tools, but the purpose is under-specified.
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 about when to use this tool, such as after a dialog appears or in contrast to other browser actions. The description gives no context for the appropriate situation.
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 |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the description doesn't need to re-state them. The description adds no extra behavioral detail about side effects (e.g., triggering JavaScript events, potential menu changes). With annotations present, the bar is lower, but there's still room for more transparency about outcomes.
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—six words, no redundancy, and perfectly focused on the action. It follows a clear verb-object structure with no extra fluff, making it easy to parse and understand.
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 simple interaction tool, the description, alongside the parameter schema and annotations, is adequate. It lacks details on return values (but no output schema exists) and does not mention any prerequisites or setup. Given the simplicity, it covers essential context without being overlong.
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?
Both parameters (target and element) have descriptions in the schema, achieving 100% coverage. The tool description does not add further meaning beyond the schema; it simply restates the action. Since schema coverage is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (hover) and the target (element on page). It distinguishes itself from sibling tools like click, drag, and type by specifying the hover action. However, it lacks detail about what the hover does (e.g., showing tooltips or hover menus), but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use hover versus other interactions. While it's intuitive that hover is for mouse-over actions, the description doesn't mention edge cases or alternative tools (e.g., use click for activating, hover for previews). It provides minimal implicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns full details (headers and body) of a single network request, or a single part if part is set. Use the number from browser_network_requests.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | Return only this part of the request. Omit to return full details. | |
| index | Yes | 1-based index of the request, as printed by browser_network_requests. | |
| filename | No | Filename to save the result to. If not provided, output is returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it returns headers and body and can filter to a part, but does not elaborate on output structure or edge cases. Given annotation coverage, a 3 is appropriate.
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 with no redundant wording. The main purpose is front-loaded, the part option is explained, and the source of the index is given. Every sentence earns its place.
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 retrieval tool with full schema coverage and annotations, the description is sufficient. It explains the return type (full details or part) and the index source. It lacks explicit output format details, but the enum values for 'part' are self-explanatory.
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 coverage is 100% with descriptions for all parameters, so the schema already documents them. The description adds critical value by explaining that 'index' comes from browser_network_requests, which is not in the schema, enhancing clarity.
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 returns full details of a single network request, with an optional 'part' parameter to narrow down. It distinguishes from the sibling tool browser_network_requests by referencing its index, making the purpose unambiguous.
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 instruction 'Use the number from browser_network_requests' explicitly guides when to use this tool—after obtaining a listing. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Only return requests whose URL matches this regexp (e.g. "/api/.*user"). | |
| static | Yes | Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false. | |
| filename | No | Filename to save the network requests to. If not provided, requests are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable context about the temporal scope ('since loading the page') and the numbered list format, which goes beyond annotations without contradicting 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?
Two concise sentences with no redundancy. The primary action is front-loaded, and the companion tool reference is placed efficiently at the end. Every word earns its place.
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?
The description tells the agent what the tool returns (a numbered list) and how to proceed for details. Since there is no output schema, this is essential. It does not describe potential error cases or edge scenarios, but for a read-only list tool with strong schema coverage, it is sufficiently complete.
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?
All three parameters have schema descriptions covering 100% of the input schema. The tool description does not add any additional meaning to the parameters themselves, so the baseline of 3 applies; it neither enhances nor detracts from what the schema already provides.
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 it returns a numbered list of network requests since page load, and explicitly differentiates from the sibling tool browser_network_request by instructing to use that tool for details. This is a specific verb+resource with a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage pattern: first call this tool to get a list, then use browser_network_request with the number for full details. This is clear guidance on when to use it versus its companion, though it does not mention any other alternatives or exclusions.
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?
The description does not mention any side effects, such as triggering keyboard events or potential destructive behavior. The annotations indicate destructiveHint: true, but the description adds no additional behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — a single sentence that directly conveys the action. No unnecessary information or repetition.
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 simple action with a single well-defined parameter, the description is adequate. It lacks mention of when to use this tool (e.g., for shortcuts or navigation keys) but is otherwise complete for basic invocation.
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 parameter 'key' is fully described in the schema with examples, and schema coverage is 100%. The description adds minimal extra meaning ('on the keyboard') but doesn't clarify key formats or special keys, which is already covered by the 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 action (press) and the resource (key on the keyboard). It is distinct from broader actions like navigate or click, though it does not explicitly differentiate from browser_type (typing) or browser_click (clicking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., browser_type for text entry or browser_click for mouse actions). The description lacks any contextual cues for choosing this tool.
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?
The description does not disclose any behavioral traits beyond the bare action. Annotations already indicate it is not read-only and is destructive, but the description adds no extra context about side effects like layout reflows or potential viewport changes.
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, short declarative sentence with no unnecessary words. It is perfectly concise and well-structured for the simple action it describes.
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 simple tool, the description is adequate, but it lacks any extra context such as units (e.g., pixels), constraints, or when resizing might be appropriate. Given the simplicity and schema coverage, it is minimally complete but not rich.
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 already provides descriptions for both parameters (width and height), achieving 100% coverage. The description adds no additional meaning about the parameters, so it stays at the baseline of 3.
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 (resize) and the resource (browser window), making it distinct from sibling tools like navigate or click. However, it lacks any nuance about whether it resizes the viewport or the entire window, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention scenarios like adjusting viewport for responsive testing or any conditions that would make it preferable to other navigation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | A JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction. For example: `async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }` | |
| filename | No | Load code from the specified file. If both code and filename are provided, code will be ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the description's 'Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent' adds specific severity and mechanism beyond the generic flags. This enhances transparency without contradicting annotations, though it could also mention side effects or sandboxing if any.
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 sentence that packs purpose and a crucial warning. It front-loads the action and immediately follows with the risk, maximizing information density with zero filler. Excellent structure.
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 (arbitrary code execution) and the lack of an output schema, the description does not mention the return value or error behavior. The example in the code parameter shows a return, but that's in the schema. For an advanced tool, this is a notable gap, but the core purpose and danger are clear. A 3 reflects the missing return semantics and operational details.
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 covers 100% of parameters with detailed descriptions, including the precedence rule for code vs filename. The tool description adds no additional parameter meaning beyond the schema, so a baseline of 3 is appropriate. The schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run a Playwright code snippet.' It specifies the resource (Playwright code) and immediately flags the critical distinction from siblings with 'Unsafe: executes arbitrary JavaScript ... RCE-equivalent.' This unambiguous verb+resource plus the danger label leaves no ambiguity about what the tool does and separates it from all other browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a strong warning about safety ('Unsafe', 'RCE-equivalent') but does not explicitly state when to use it versus alternatives. It implies it's for advanced custom logic, but there is no direct 'use this only if...' or mention of safer alternatives. The warning serves as a caution but not a full usage guide.
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 |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| values | Yes | Array of values to select in the dropdown. This can be a single value or multiple values. | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, so the description does not contradict that. But the description adds no further behavioral detail (e.g., side effects on the page). With annotations present, the bar is lower, and the description is neutral.
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 concise sentence with no redundant words. It is well-structured and to the point.
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?
The tool is simple and the schema covers all parameters. The description is short but sufficient for a basic understanding. It does not specify whether values are labels or values, but that is a minor omission given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for target and values. The tool description itself does not explain parameters beyond what the schema already provides, so it adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (select) and the target (option in a dropdown), distinguishing it from more general actions like click or type. However, it does not explicitly contrast with sibling tools, so it misses a bit of 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. It does not mention when selecting is appropriate or when other actions (e.g., click, type) might be preferred.
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 |
|---|---|---|---|
| boxes | No | Include each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect) | |
| depth | No | Limit the depth of the snapshot tree | |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds 'capture' but no further behavioral detail beyond what annotations convey.
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 concise sentence. The phrase 'this is better than screenshot' adds some comparative value but could be considered slightly extraneous.
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?
There is no output schema and the description does not explain what format the snapshot takes, how parameters like depth or target affect the result, or what kind of accessibility information is included. This leaves important context missing for an agent deciding whether and how to call the 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 covers all 4 parameters with descriptions, so the baseline is 3. The description does not add any additional parameter meaning or usage notes beyond the 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?
States a clear action ('capture') and object ('accessibility snapshot of the current page'), and distinguishes itself from screenshot with a comparative remark, though 'better than screenshot' is somewhat vague.
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?
Gives minimal guidance by saying 'better than screenshot', but does not explicitly state when to use this tool over alternatives like browser_evaluate or browser_console_messages, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, create, close, or select a browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to in the new tab, used for new. | |
| index | No | Tab index, used for close/select. If omitted for close, current tab is closed. | |
| action | Yes | Operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. However, the description adds no behavioral context beyond what the schema provides (e.g., index omission for close closes current tab is in schema). No mention of side effects like tab switching or browser-level changes.
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 sentence that efficiently lists all supported actions. It is front-loaded with verbs and avoids unnecessary words.
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?
The tool has multiple actions and a required action parameter. The description lists the actions but does not explain action-specific requirements (e.g., URL required for new, index for close/select) or edge cases like closing the last tab. Given the schema covers parameter details, the description is adequate but not rich. With no output schema, the agent must infer return values from the action.
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 each parameter having a description (url, index, action with enum). The tool description adds no parameter-level detail, so it does not go beyond schema. Baseline 3 applies.
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 a specific resource (browser tab). It distinguishes from siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab) by focusing on tab 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 implies usage through the list of actions but provides no explicit when-to-use guidance or exclusions. Given siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab), an agent might benefit from explicit differentiation, but the actions themselves are clear enough that usage is implied.
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. If unset, inferred from the filename extension, otherwise png. | |
| scale | Yes | Image resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css. | css |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg|webp}` if not specified. Prefer relative file names to stay within the output directory. | |
| 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 and destructiveHint=false, covering safety. The description adds a key behavioral trait: the output is not interactive ('You can't perform actions based on the screenshot'), which is not captured by annotations. This adds meaningful context about the tool's limitations beyond the structured data.
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 concise sentences with no redundant phrasing. The core purpose is stated first, followed by a critical limitation and alternative, maximizing informativeness per word.
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 screenshot tool with comprehensive schema documentation and safety annotations, the description covers the essential decision points: when to use it and when not to. It doesn't explain return formats or error handling, but those are less critical given the tool's simplicity and the annotations' coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 6 parameters. The description adds no parameter-specific information, and the baseline of 3 is appropriate since the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Take') and resource ('screenshot of the current page'). Explicitly distinguishes from browser_snapshot by stating what it is not for ('You can't perform actions based on the screenshot'), making it clear which tool to use for captures vs. interactions.
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?
Provides explicit when-not-to-use guidance: 'You can't perform actions based on the screenshot' and directs to the alternative 'use browser_snapshot for actions'. This clearly routes an agent to the correct tool for interactive needs while implying this tool is for visual captures.
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 |
|---|---|---|---|
| text | Yes | Text to type into the element | |
| 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. | |
| submit | No | Whether to submit entered text (press Enter after) | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true and readOnlyHint=false already signal that this tool can modify state, so the description does not contradict that. However, the main description adds no additional behavioral context beyond the annotations, such as whether typing overwrites existing content or triggers page events. The parameter descriptions do mention key-handler triggering and Enter submission, but the main description itself stays shallow.
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, focused sentence with no filler or repetition. It front-loads the verb and object, making the tool's primary purpose immediately obvious.
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 tool with several closely related siblings (fill_form, press_key, click), the description is too thin to fully orient an agent. It lacks any mention of when typing is appropriate, how the target is resolved, or what side effects to expect, so the agent must rely on parameter descriptions and external context to make a confident choice.
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 coverage is 100%, so the baseline is 3 because the input schema already documents all five parameters. The main description, 'Type text into editable element,' adds no meaning beyond the schema's parameter descriptions, which already define text, slowly, submit, target, and element clearly enough.
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 states a clear action ('Type text') and a clear target ('editable element'), which distinguishes it from many sibling tools at a high level. It is slightly vague about whether 'editable element' includes textareas, contenteditable regions, or only input fields, but the core purpose is unambiguous.
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 gives no guidance on when to prefer this tool over sibling tools such as browser_fill_form or browser_press_key. It does not mention exclusions, prerequisites, or scenarios where typing would be inappropriate, 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.
Wait for text to appear or disappear or a specified time to pass
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The text to wait for | |
| time | No | The time to wait in seconds | |
| textGone | No | The text to wait for to disappear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the readOnlyHint by explaining that it waits for text appearance/disappearance or a time delay. However, it does not specify what happens if multiple parameters are provided or if none are provided, so behavior is not fully transparent.
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 concise sentence that front-loads the core action and conditions. It contains no unnecessary words and is 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?
For a simple wait tool with no output schema, the description covers the main use cases, but it omits edge cases such as default behavior when no parameters are supplied, timeout behavior, or error conditions. These gaps make it only partially complete.
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 schema descriptions already cover each parameter individually, and the tool description mostly restates them. It does not clarify the relationship between text, textGone, and time (e.g., whether they are mutually exclusive or combinable), so minimal semantic value is added beyond the 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 tool waits for a condition: text to appear, text to disappear, or a specified time to pass. This distinguishes it from sibling tools like click, navigate, or type, and its purpose is immediately understandable.
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 when to use the tool (when waiting for page state or a delay), but it does not explicitly state when to prefer this over alternatives or how to choose among text, textGone, and time parameters. It provides functional guidance but lacks explicit usage conditions.
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.
v0.0.79browser_clickbrowser_closebrowser_console_messagesbrowser_dragbrowser_dropbrowser_evaluatebrowser_file_uploadbrowser_fill_formbrowser_findbrowser_handle_dialogbrowser_hoverbrowser_navigatebrowser_navigate_backbrowser_network_requestbrowser_network_requestsbrowser_press_keybrowser_resizebrowser_run_code_unsafebrowser_select_optionbrowser_snapshotbrowser_tabsbrowser_take_screenshotbrowser_typebrowser_wait_forScored across 24 tools
Each tool has a clearly distinct purpose, covering actions like navigation, clicking, typing, screenshots, network requests, file upload, and dialog handling. Even similar tools like browser_snapshot and browser_take_screenshot are differentiated by their intended use (actions vs. visual capture).
All tools share the 'browser_' prefix, and most follow a verb_noun or verb pattern (e.g., browser_click, browser_fill_form). However, a few are noun-based (e.g., browser_network_requests, browser_tabs) which breaks the verb-first convention slightly, but the overall pattern remains predictable.
With 24 tools, the set is extensive but well-scoped for a full browser automation server. Each tool addresses a specific operation, and the count is appropriate for the domain, though it borders on the heavier side.
The toolset covers core browser automation workflows: navigation, clicks, forms, network, screenshots, accessibility, dialogs, file upload, and tabs. Minor gaps exist (e.g., no direct tool for scrolling or getting current URL), but these do not significantly hinder common agent tasks.
E2LLM gives your AI eyes and hands in a real browser: structured perception (SiFR) plus action.
Official Browserless MCP server: browser automation, scraping, screenshots and PDFs for AI agents.
Control a real browser from AI agents: navigate, click, type, screenshot, read the page.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.