Implementa Playwright MCP en Render con un clic. Obtén un servidor de MCP alojado con Chromium headless que tus herramientas de IA puedan usar a través de HTTP: sin instalar un navegador local ni npx en cada máquina.
https://github.com/user-attachments/assets/0f31c279-f2e0-431f-a854-50677bd800c5
Playwright MCP es un servidor del Model Context Protocol que permite a un LLM abrir un navegador real, navegar, hacer clic, escribir y leer páginas mediante instantáneas de accesibilidad estructuradas (no capturas de pantalla). Normalmente se ejecuta localmente con npx @playwright/mcp. Esta plantilla lo ejecuta como un único servicio web de Render, de modo que cualquier cliente MCP pueda conectarse a una URL HTTPS compartida.
Es un envoltorio fino sobre la imagen oficial mcr.microsoft.com/playwright/mcp (Chromium headless ya incluida), sin cambios en el código fuente. El envoltorio añade los flags que Render necesita (--headless, --no-sandbox, además de --port y --allowed-hosts desde el entorno) y un pequeño control de acceso bearer token delante del servidor, porque Playwright MCP no tiene autenticación propia.
Autenticado por defecto. Playwright MCP no tiene autenticación en modo HTTP e incluye una herramienta equivalente a RCE; por eso esta plantilla no lo publica directamente: las peticiones deben llevar
Authorization: Bearer $MCP_TOKEN, y Render genera ese token por ti en el momento del despliegue. Lee Seguridad para saber qué protege y qué no.
Para ver la lista completa de herramientas, opciones de configuración y configuración de clientes, consulta el README upstream.
Related MCP server: Playwright MCP
Un único servicio web de Render ejecuta la imagen oficial de Playwright MCP detrás de un controlo de acceso bearer token. Un cliente MCP se comunica por Streamable HTTP con /mcp a través del borde TLS de Render; el controlo de acceso verifica el token y reenvía el resto al servidor MCP en loopback, que maneja un Chromium headless en el mismo contenedor y devuelve instantáneas de accesibilidad.
┌─────────────┐ HTTPS /mcp ┌────────────────────────────────────────────────┐
│ MCP client │ ──────────────► │ Render web service (Docker, standard plan) │
│ (Claude, │ + Bearer │ │
│ Cursor, …) │ token │ render-entrypoint.sh │
│ │ │ │ reads PORT, allowed hosts │
│ │ Streamable │ ▼ │
│ │ ◄────────────── │ render-auth-proxy.mjs :$PORT (public) │
└─────────────┘ snapshots │ │ 401 unless the Bearer token matches │
│ ▼ │
│ node /app/cli.js 127.0.0.1:8931 (loopback) │
│ │ │
│ ▼ │
│ headless Chromium (baked into base image) │
└────────────────────────────────────────────────┘Cómo se ensambla un despliegue:
Archivo | Rol |
Blueprint. Declara el único servicio web de Docker, su plan/región, la variable de entorno | |
Envoltorio fino sobre | |
Lee | |
PID 1. Node de pura librería estándar, sin dependencias: rechaza cualquier petición sin | |
El límite de tamaño del control de acceso, mantenido separado porque es la única pieza con estado que vale la pena comprobar por sí sola: tope de ventana fija para los intentos de autenticación fallidos, contados en todos los clientes. Lo importa el proxy, por lo que | |
Compila la imagen y prueba el envoltorio de extremo a extremo: falla cerrado sin | |
Documenta los mismos parámetros para ejecutar el contenedor localmente. |
Propiedades clave:
Envolatorio fino, sin fork de la herramienta. La versión de Playwright MCP está fijada por la etiqueta de la imagen base en Dockerfile.render; las actualizaciones son tocar esa etiqueta en una línea (consulta Actualización de Playwright MCP).
Sin base de datos, sin disco que llenar. El único secreto, MCP_TOKEN, lo generó Render en el despliegue. El navegador mantiene por defecto el perfil persistente de upstream, por lo que los inicios de sesión se mantienen entre peticiones durante toda la vida de la instancia; útil para un servidor tuyo solo, como asume está plantilla (consulta Configuración).
Autenticada y con cierre ante faltas. El controlador de acceso lo añade esta plantilla, no upstream. Si no se establece MCP_TOKEN, el contenedor se niega a iniciarse, así que no hay configuración en la que el servidor quede expuesto sin autorización (consulta Seguridad).
Para desplegar, necesitas:
Una cuenta de Render — crear una es gratis; el propio servicio se ejecuta en el tipo standard de pago (consulta Despliegue).
Una cuenta de GitHub, para hacer un fork de este repositorio (el botón Deploy lee render.yaml de un repositorio que sea tuyo).
No se necesitan claves de API ni cuentas de terceros. El único secreto, MCP_TOKEN, se genera automáticamente al desplegar: solo tienes que copiarlo en tu cliente MCP (consulta Despliegue).
Para ejecutarlo también en local (opcional — consulta Ejecución local):
Docker con BuildKit (Docker Desktop 4.6 o superior, o compatible con 4. or Docker Engine 23+). Dockerfile.render usa una directiva # syntax= y COPY --chmod, ambas funciones de BuildKit.
Un cliente MCP al que apuntarlo (p. ej., Claude Code, Cursor), o simplemente curl.
No necesita Node.js ni Playwright ni un Chromium local: la imagen base ya incluye todo eso.
Haz clic en Deploy to Render arriba (o bifurca este repositorio y crea un nuevo Blueprint a partir de él).
Render lee la información del blueprint de permitir Render y aprovisiona un único servicio web Docker (playwright-mcp) en el plan standard.
Espera a que el despliegue pase a live (en línea). Tu servidor estará en https://<tu-servicio>.onrender.com/mcp.
Copia MCP_TOKEN de la página Environment del servicio en el Dashboard de Render; Render lo generó por ti. Tu cliente MCP debe enviarlo como Authorization: Bearer <token> (consulta Usar la aplicación); sin él, cada petición tendrá un 401.
Antes de apuntar algo sensible, lee Seguridad. The token is the only thing between the Internet and the code execution in this container, so treat it like the password — and further tighten it if possible.
Sizing del plan: Chromium headless con memoria (OOM) en el nivel gratuito /
starter(512 MB), así que el blueprint usa por defectostandard(2 GB). Cambia a un plan inferior solo si has confirmado que tu carga funciona con menos.
Apunte cualquier cliente MCP al endpoint /mcp de tu servicio y envía MCP_TOKEN como token saltador. Por ejemplo, con Claude Code:
claude mcp add --transport http playwright https://<your-service>.onrender.com/mcp \
--header "Authorization: Bearer <your-MCP_TOKEN>"O el ciente de la configuración:
{
"mcpServers": {
"playwright": {
"url": "https://<your-service>.onrender.com/mcp",
"headers": {
"Authorization": "Bearer <your-MCP_TOKEN>"
}
}
}
}Si el cliente devuelve un 401, la cabecera falta o el token no coincide con el valor actual del Dashboard.
Puedes pedirle a tu asistente que navegue… por ejemplo: "Abre example.com y dame el título de la página y el encabezado principal."… que combine a las herramientas de Playwright MCP contra tu navegador alojado y devuelva ese resultado.
Opcional, el camino de despliegue anterior no necesita nada de esto. Útil si quieres modificar render-entrypoint.sh y ver el efecto antes de enviar.
git clone https://github.com/render-examples/playwright-mcp-render.git
cd playwright-mcp-render
cp .env.example .env # then set MCP_TOKEN, e.g. to `openssl rand -hex 32`
docker build -f Dockerfile.render -t playwright-mcp-render .
docker run --rm --env-file .env -p 10000:10000 playwright-mcp-renderCuando esté listo, el contenedor imprime el Listening on … de upstream y luego el [auth] Bearer-token gate listening … del controlador, **ese orden es clave porque el controlador mantiene el puerto público cerrado hasta que el servidor detrás acepta, ** y que el último line es el that indica que el servicio eshttps://usable. (La línea [startup] de arriba imprime una URL https:// — ese esquema es para el despliegue; localmente usa http://.) Verifica el estado con un handshake de MCP: exporta el mismo token que pusiste en .env primero, para que la cabecera siguiente se resuelva:
curl -sS -X POST http://localhost:10000/mcp \
-H "Authorization: Bearer $MCP_TOKEN" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'Deberías obtener un bloque serverInfo que nombre de CLI Playwright, o si el Authorization salta, 401 Unauthorized. Entonces, apunta un cliente a http://localhost:10000/mcp igual que lo harías con la dirección del despliegue.
MCP_TOKENes la única variable de entorno que debes suministrar; el contenedor se cae sin ella sin más. El resto de.enves comodidad: fuera de Render no hayRENDER_EXTERNAL_HOSTNAME, así que la entrada usaPORT=10000y--allowed-hosts *como valor por defecto.
¿Prefieres no ejecutar Docker? Upstream sirve el mismo servidor directamente: npx @playwright/mcp@latest --port 10000 — ten en cuenta that this is whatever npm publishes, esnoor esa, la etiqueta que fija la plantilla, y además no incluye el control de acceso (que es aportación de esta plantilla). Ese camino tampoco es lo que Render despliega, así que verifica tus cambios dentro del contenedor antes de hacer el push.
Todo se define en render.yaml y el archivo de entorno .env.example documenta los mismos parámetros para ejecutar en localmente.
Variable | Default | Para qué |
|
| El puerto en el que se expone el gate por el que Render enruta. |
| generado por Render | Obligatorio. Token para pasarlas en cada petición a través de la cabecera |
|
| Puerto loopback del servidor MCP detrás del control el. Enhanced only if there is a collision with something inside the container. |
.env.example también lista PLAYWRIGHT_MCP_HOST, PLAYWRIGHT_MCP_HEADLESS y PLAYWRIGHT_MCP_NO_SANDBOX. Estos parámetros solo importan cuando ejecutas el servidor directamente (fuera de esta imagen) — en Render, render-entrypoint.sh siempre pasa las banderas CLI equivalentes, y las banderas CLI tienen prioridad, así que configurarlos en el panel de Render no tiene ningún efecto. La única excepción es PLAYWRIGHT_MCP_ALLOWED_HOSTS, que el entrypoint sí respeta.
El entrypoint limita la comprobación de host del servidor al nombre de host onrender.com de tu propio servicio automáticamente mediante RENDER_EXTERNAL_HOSTNAME de Render. Si añades un dominio personalizado, las solicitudes dirigidas a él serán rechazadas por la comprobación de host hasta que definas PLAYWRIGHT_MCP_ALLOWED_HOSTS (separado por comas, por ejemplo, myapp.com,myapp.onrender.com; * desactiva la comprobación).
El entrypoint no pasa ninguna bandera de perfil, por lo que obtienes el valor predeterminado de Playwright MCP: un perfil persistente en el sistema de archivos del contenedor (~/.cache/ms-playwright/mcp-*). Merece la pena conocer dos consecuencias:
Los inicios de sesión sobreviven entre llamadas — normalmente es lo que quieres. Autentícate una vez a través del navegador alojado y las sesiones posteriores reutilizarán la sesión. Cada cliente que apunte a la URL comparte ese único perfil, así que esto asume que el servicio es tuyo (consulta Seguridad). No se adjunta ningún disco, por lo que el perfil se borra al reiniciar o volver a implementar.
Clientes concurrentes pueden entrar en conflicto. El proyecto de origen señala que un perfil persistente "solo puede ser usado por una instancia del navegador a la vez, por lo que los clientes MCP concurrentes que compartan el mismo espacio de trabajo entrarán en conflicto" — así que dos editores apuntando a una misma URL pueden colisionar. Escalar a más de una instancia también le da a cada instancia su propio perfil.
Para modificar cualquiera de estos comportamientos, edita render-entrypoint.sh:
Quieres | Añade |
Un perfil nuevo en memoria por sesión, descartado al final |
|
Un perfil que sobrevive a redespliegues (sesiones guardadas) | un Render Disk junto con |
Playwright MCP expone browser_run_code_unsafe, descrito en el proyecto de origen como: "Ejecuta un snippet de código de Playwright. No seguro: ejecuta JavaScript procesado y arbitrario en el proceso del servidor de Playwright y es equivalente a RCE." En la versión fija, está enumerado bajo Core automation, no entre las capacidades opcionales, y --caps solo habilita capacidades adicionales (vision, pdf, devtools) — quindi no puede eliminar este tool, y ninguna bandera descarta herramientas individuales. Cualquier persona que pueda llamar a este servidor puede ejecutar código en tu contenedor como el usuario del contenedor, y llegar a tus otros servicios de Render a través de la red privada.
El proyecto de origen no incluye el inicio de autenticating en modo HTTP, lo que es defendible cuando el servidor es npx en el loopback de tu portátil. En Render its afford a public URL, so this template add the missing door.
render-auth-proxy.mjs es lo único que escucha en $PORT. Responde 401 a cualquier solicitud sin Authorization: Bearer $MCP_TOKEN y reenvía el resto al servidor MCP, que se une a 127.0.0.1 y nobody se publica. Específicamente:
Falla de forma segura (cierre por defecto). Sin MCP_TOKEN no hay inicio: no hay deliberadamente ninguna bandera de para desactivar la comprobación, por lo que ninguna mala configuración deja al servidor anónimo.
Secreto generado, no predeterminado. render.yaml usa generateValue: true, de modo que cada servicio recibe su propio token, generado una vez cuando se crea el servicio y estable a través de los redespliegues, por lo que los clientes siguen funcionando: además hay no que no hay credencial común en este repo que pueda filtrarse.
Comparación de tiempo constante de los resúmenes SHA-256, así que la comprobación no filtra el token byte a byte, y un prefijo del token no se acepta.
Nunca registra el token. Los rechazos solo loguean el método, la ruta y el código 401 — nada de lo que presenta el cliente.
Limita él la adivinanza. Los intentos fallidos comparten un presupuesto global: diez en un minuto y el resto de la ventana obtiene 429 con Retry-After, más una sola línea de registro en lugar de una po cada intento. El presupuesto solo se gasta con solicitudes que iban a ser rechazadas de todos modos, así que un token válido no está sujeto a ello nunca — el bloqueo no puede apuntarte a ti, y siempre puedes volver a entrar mientras un atacante está bloqueado. No es deliberadamente por cliente: esta puerta da servicio a un único secreto compartido, por lo que lo que vale la pena garantizar es un techo total a la velocidad de adivinanza, y un límite por dirección no proporciona esto — el enemigo que va rotando direcciones cada vez consigue una nueva presupuesto.
Detiene el token en la puerta. El encabezado Authorization no se reenvía al MCP, junto con los encabezados hop-by-hop que un proxy está obligado a eliminar. Las actualizaciones de conexión (WebSocket y similares) se contestan con 501 en vez de proxyse, ya que el transporte MCP nunca necesita una.
Esto es una puerta, no defensa en profundidad. No aísla el RCE, no limita lo que puede hacer una persona autenticada, ni te da identidad por cliente: cualquiera que con el token es el mismo principal, y el límite de tasa anterior frena la adivinanza, no el mal uso de un token que ya se filtró. Si puedes, añade una capa más fuerte encima:
Limita quién puede llegar a este servicio. Las reglas de IP entrante restringidas a tus direcciones conocidas (planes Scale y Enterprise) significan que un token robado no se puede usar desde cualquier otro lugar.
No lo expongas al público. Si su cliente MCP es otro servicio de Render, cambie type: webee a type: pserv en render.yaml para que se transforme en un servicio privado — sin URL pública, esencialmente más seguro, y el token sigue aplicando. Tenga en cuenta que no recibe RENDER_EXTERNAL_HOSTNAME, así que la comprobación de host vuelve a * y el banner de inicio imprime una URL localhost; alcáncelo a través de la red privada en la que reside.
Trata el token como una contraseña. Manténgalo fuera de configuraciones y rastreadores de incidencias; roundí celo en el panel de control si se pudiera haber filtrado (un despliegue revise el nuevo valor) y suspenda o elimine el servicio. Después de usar, no lo utilice más.
Cuídalo. Los logs del servicio y las métricas son cómo se darías cuenta de un uso que no iniciaron; las líneas 401 significan que alguien está llamando.
Una consecuencia de ese presupuesto compartido que se debe conocer antes de depurar: mientras el atacante gasta el presupuesto, una solicitud con el token incorrecto obtiene 429 en vez de 401. Cualquiera puede mantenerlo vacío indefinidamente: con diez solicitudes rechazadas por minuto ¿Y si alguien? Quien; así que esto puede ser a un servicio que recibe escaneos de fondo, este puede ser un estado normal en lugar de inusual. Si es una prueba con un token que parece obsoleto (por ejemplo, rotado en el Dashboard, o copiado de un servicio antiguo), el código de estado no te dirá eso, y la solución es revisar el token y no aguardar el Retry-After. La petición con el token correct no se ve afectada en ningún caso, lo que hace que aceptar este compromiso sea razonable: cualquiera puede agotar el presupuesto, pero el bloqueo que produce no puede apuntarse contra ti.
La verificación de host que el entrypoint configura (ver Configuración) es una comprobación del encabezado Host contra el rebote de captura de DNS (DNS rebinding) — no control de acceso. Esta no impide que una petición directa con el token válido llegue.
La versión queda fijada en un solo lugar: la etiqueta de la imagen base en Dockerfile.render. Para subirla, cambia etiqueta y actualiza la imagen base, ejecuta commit y vuelve a implementar (las imágenes runtime: docker no se despliegan cuando se mueve; un nuevo despliegue tira de la nueva imagen base).
Luego vuelve a comprobar las dos afirmaciones en Seguridad contra el README del proyecto original con la nueva etiqueta: si browser_run_code_unsafe sigue siendo una herramienta de automatización básica no opcional, y si --caps solo sigue agregando capacidades. Actualiza igualmente el enlace permanente de esa sección a la nueva etiqueta, ya es la única otra parte donde aparece una versión literal, y el enlace permanente ha de llevar una.
Después vuelve a verificar la puerta de enlace, ya que depende de la superfície HTTP del projecto. npm run test:wrapper cubre la lógica de la propia puerta en unos segundos sin Docker (el presupuesto de errores, el proxy que responde con 401/429/200, con un upstream espejo), y ./render-smoke-test.sh compila la imagen nueva y la comprueba de extremo a extremo (401 sin el encabezado, 429 tras repetidos intentos con tokens defectuosos, una conexión con el token correcto, una llamada real a la herramienta mediante el tránsito SSE, cierre limpio). El CI ejecuta lo dos en cada PR, así que que que tú abrعامi una PR es equivalente. Si el proyecto finalmente publica ayuda autenticación de verdad, prueba a usarla y borra render-auth-proxy.mjs; este archivo solo existe para llenar ese vacío.
No es una versión que debas mantener sincronizada: el campo
versionenpackage.json. Este repo es un fork de microsoft/playwright-mcp, por lo que ese campo es el propio letrero de la versión de npm del proyecto — — y el despliegue nunca lo ve (usa,Dockerfile.rendersolo copiarender-entrypoint.sh,render-auth-proxy.mjsyrender-auth-limiter.mjs). Espera que se difiera de la etiqueta de la imagen; déjalo como esta.
Basado en icrosos/playwright-mcp · Se despliega en render.
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.
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 | Yes | Image format for the screenshot. Default is png. | 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}` 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?
The annotations already indicate read-only and non-destructive behavior. The description adds useful context beyond annotations by clarifying that screenshots are not suitable for interaction and that browser_snapshot should be used for actions. This is helpful but not extensive.
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 concise and well-structured: two sentences that front-load the core purpose and immediately follow with a crucial usage caveat. There is no unnecessary verbosity 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?
Given the simple nature of the tool and the rich schema annotations, the description is largely complete. It could mention that screenshots are for visual inspection, but the title and schema fill most gaps. The explicit distinction from browser_snapshot adds important 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?
The schema description coverage is 100%, so the baseline is 3. The description itself does not add parameter details, but the schema already provides clear explanations for each parameter, including enums, defaults, and constraints.
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: 'Take a screenshot of the current page.' It also distinguishes itself from browser_snapshot by explicitly noting that screenshots cannot be used for actions, which helps differentiate it from a key sibling tool.
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 provides explicit when-not-to-use guidance by stating 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This directly names the alternative tool and the condition for choosing it.
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.77browser_clickbrowser_closebrowser_console_messagesbrowser_dragbrowser_dropbrowser_evaluatebrowser_file_uploadbrowser_fill_formbrowser_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 23 tools
Each tool serves a distinct browser automation purpose: navigation, actions (click, hover, drag), input (type, press_key, fill_form), page inspection (snapshot, screenshot, network/console), and session management (tabs, resize, close). No two tools overlap in function; even similar tools like browser_evaluate and browser_run_code_unsafe are clearly separated by context (page vs server).
All 23 tools follow the consistent pattern of 'browser_' prefix followed by a lowercase snake_case verb or verb phrase (e.g., browser_navigate, browser_network_requests). The naming is uniform, descriptive, and predictable, making it easy to infer tool behavior from the name alone.
At 23 tools, the count falls in the 16–25 range, which feels heavy per calibration. However, the domain of browser automation is inherently broad, and each tool addresses a specific action or inspection need. Still, the number exceeds the typical well-scoped 3–15 range, meriting a borderline score.
The toolset covers core browser workflows comprehensively: navigation (navigate, back), user input (click, type, press_key, select_option, fill_form), page diagnostics (snapshot, screenshot, console, network), and browser management (tabs, resize, close). Minor gaps exist (e.g., no explicit 'reload' or 'go forward' tool), but these can be handled via browser_evaluate or browser_navigate, so the surface is largely complete.
Official Browserless MCP server: browser automation, scraping, screenshots and PDFs for AI agents.
Web scraping, browser automation, screenshots and AI data extraction for AI agents via MCP.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Control a real browser from AI agents: navigate, click, type, screenshot, read the page.