Automatización avanzada del navegador
Navegue a cualquier URL con estrategias de carga personalizables
Capturar capturas de pantalla de página completa o de elementos específicos
Realizar interacciones DOM precisas (hacer clic, rellenar, seleccionar, pasar el cursor)
Ejecutar JavaScript arbitrario en el contexto del navegador con captura de registros de la consola
Cliente API potente
Ejecutar solicitudes HTTP (GET, POST, PUT, PATCH, DELETE)
Configurar los encabezados de solicitud y el contenido del cuerpo
Procesar datos de respuesta con formato JSON
Manejo de errores con retroalimentación detallada
Gestión de recursos de MCP
Acceder a los registros de la consola del navegador como recursos
Recuperar capturas de pantalla a través de la interfaz de recursos de MCP
Sesión persistente con instancia de navegador completa
Capacidades del agente de IA
Encadenar múltiples operaciones del navegador para tareas complejas
Siga instrucciones de varios pasos con recuperación inteligente de errores
Automatización de tareas técnicas mediante instrucciones en lenguaje natural
Related MCP server: Browserbeam MCP Server
Haga clic en cualquier marca de tiempo para saltar a esa sección del video.
00:00 - Búsqueda de MCP en Google
Navegación a la página principal de Google y búsqueda de "Protocolo de Contexto de Modelo". Demostración de Claude Desktop utilizando la integración de MCP para realizar una búsqueda web básica y procesar los resultados.
00:33 - Captura de pantalla
Captura de pantalla de los resultados de búsqueda con un nombre de archivo personalizado y su visualización en el Finder. Muestra cómo Claude puede capturar y guardar contenido visual de páginas web durante la automatización del navegador.
01:00 - Búsqueda en Wikipedia
Navega a Wikipedia.org y busca "Protocolo de Contexto de Modelo". Esto ilustra la capacidad de Claude para interactuar con diferentes sitios web y su funcionalidad de búsqueda mediante la integración de MCP.
01:38 - Interacción del menú desplegable I
Navegación a un sitio web de prueba (the-internet.herokuapp.com/dropdown) y selección de la "Opción 1" en un menú desplegable. Esto demuestra la capacidad de Claude para interactuar con los elementos del formulario y realizar selecciones.
01:56 - Interacción del menú desplegable II
Al cambiar la selección a "Opción 2" en el mismo menú desplegable, se demuestra la capacidad de Claude para manipular el mismo elemento de formulario varias veces y realizar diferentes selecciones.
02:09 - Completar el formulario de inicio de sesión
Navegación a una página de inicio de sesión (the-internet.herokuapp.com/login) y rellenado el campo de nombre de usuario con "tomsmith" y el de contraseña con "SuperSecretPassword!". Demostración de la automatización del llenado de formularios.
02:28 - Envío de inicio de sesión
Enviar las credenciales de inicio de sesión y completar el proceso de autenticación. Muestra la capacidad de Claude para activar el envío de formularios y navegar por procesos de varios pasos.
02:36 - Ejecución de solicitud de API
Se realiza una solicitud GET al punto final de la API JSONPlaceholder. Esto demuestra la capacidad de Claude para realizar llamadas directas a la API y procesar los datos devueltos mediante la integración con MCP.
Node.js 16 o superior
Escritorio de Claude
Dependencias del dramaturgo
npm init playwright@latestEste paquete incluye Playwright y las dependencias necesarias para ejecutar la automatización del navegador. Al ejecutar npm install , se instalarán las dependencias necesarias de Playwright. El paquete es compatible con los siguientes navegadores:
Chrome (predeterminado)
Firefox
Microsoft Edge
WebKit (motor Safari)
Al usar un navegador por primera vez, Playwright instalará automáticamente los controladores correspondientes según sea necesario. También puede instalarlos manualmente con los siguientes comandos:
npx playwright install chrome
npx playwright install firefox
npx playwright install webkit
npx playwright install msedgeNota sobre Safari : Playwright no ofrece compatibilidad directa con el navegador Safari. En su lugar, utiliza WebKit, el motor de navegación que lo impulsa.
Nota sobre Edge : Al seleccionar Edge como tipo de navegador, el agente iniciará Microsoft Edge (no Chromium). Técnicamente, en Playwright, Edge se inicia usando la instancia del navegador Chromium con el parámetro de canal 'msedge', ya que Microsoft Edge se basa en Chromium.
Clonar o descargar este repositorio:
git clone https://github.com/imprvhub/mcp-browser-agent
cd mcp-browser-agentInstalar dependencias:
npm installConstruir el proyecto:
npm run buildHay dos formas de ejecutar el servidor MCP:
Abra una terminal o un símbolo del sistema
Navegar al directorio del proyecto
Ejecute el servidor directamente:
node dist/index.jsMantenga esta ventana de terminal abierta mientras usa Claude Desktop. El servidor se ejecutará hasta que cierre la terminal.
El Escritorio Claude puede iniciar automáticamente el servidor MCP cuando sea necesario. Para configurarlo:
El archivo de configuración de Claude Desktop se encuentra en:
macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Ventanas : %APPDATA%\Claude\claude_desktop_config.json
Linux : ~/.config/Claude/claude_desktop_config.json
Edite este archivo para agregar la configuración MCP del Agente del Navegador. Si el archivo no existe, créelo:
{
"mcpServers": {
"browserAgent": {
"command": "node",
"args": ["ABSOLUTE_PATH_TO_DIRECTORY/mcp-browser-agent/dist/index.js",
"--browser",
"chrome"
]
}
}
}Importante : Reemplace ABSOLUTE_PATH_TO_DIRECTORY con la ruta absoluta completa donde instaló el MCP
Ejemplo de macOS/Linux: /Users/username/mcp-browser-agent
Ejemplo de Windows: C:\\Users\\username\\mcp-browser-agent
Si ya tiene otros MCP configurados, simplemente añada la sección "browserAgent" dentro del objeto "mcpServers". A continuación, se muestra un ejemplo de configuración con varios MCP:
{
"mcpServers": {
"otherMcp1": {
"command": "...",
"args": ["..."]
},
"otherMcp2": {
"command": "...",
"args": ["..."]
},
"browserAgent": {
"command": "node",
"args": [
"ABSOLUTE_PATH_TO_DIRECTORY/mcp-browser-agent/dist/index.js",
"--browser",
"chrome"
]
}
}
}El Agente de Navegador MCP admite varios tipos de navegadores. De forma predeterminada, usa Chrome, pero puede especificar un navegador diferente de varias maneras:
Cree o edite el archivo .mcp_browser_agent_config.json en su directorio de inicio:
{
"browserType": "chrome"
}Los valores admitidos para browserType son:
chrome : utiliza Chrome instalado (predeterminado)
firefox : utiliza el navegador Firefox 'Nightly'
webkit : utiliza el motor WebKit (Nota: no se trata del propio Safari, sino del motor de renderizado WebKit que impulsa a Safari)
edge - Utiliza Microsoft Edge
Nota sobre Safari : Playwright no ofrece compatibilidad directa con el navegador Safari. En su lugar, utiliza WebKit, el motor que impulsa Safari. La implementación de WebKit en Playwright ofrece una funcionalidad similar, pero no es idéntica a la experiencia con Safari.
Al iniciar el servidor MCP manualmente, puede especificar el tipo de navegador:
node dist/index.js --browser firefoxEstablezca la variable de entorno MCP_BROWSER_TYPE :
MCP_BROWSER_TYPE=firefox node dist/index.jsAl configurar el MCP en claude_desktop_config.json de Claude Desktop, puede especificar el tipo de navegador:
{
"mcpServers": {
"browserAgent": {
"command": "node",
"args": [
"ABSOLUTE_PATH_TO_DIRECTORY/mcp-browser-agent/dist/index.js",
"--browser",
"chrome"
]
}
}
}El Agente de Navegador MCP se basa en el Protocolo de Contexto de Modelo, lo que permite a Claude interactuar con un navegador con interfaz gráfica a través de Playwright. La implementación consta de cuatro componentes principales:
Servidor (index.ts)
Inicializa el servidor MCP con el protocolo estándar del Protocolo de Contexto de Modelo
Configura las capacidades del servidor para herramientas y recursos
Establece comunicación con Claude a través del transporte stdio
Registro de herramientas (tools.ts)
Define esquemas de herramientas API y de navegador
Especifica parámetros, reglas de validación y descripciones.
Registra herramientas con el servidor MCP para el descubrimiento de Claude
Manejadores de solicitudes (handlers.ts)
Gestiona solicitudes de protocolo MCP para herramientas y recursos
Expone registros del navegador y capturas de pantalla como recursos consultables
Envía las solicitudes de ejecución de herramientas a los controladores adecuados
Ejecutor (executor.ts)
Administra el ciclo de vida del navegador y del cliente API.
Implementa funciones de automatización del navegador utilizando Playwright
Maneja solicitudes de API con manejo de errores y análisis de respuestas adecuados
Mantiene la sesión del navegador con estado entre comandos
A diferencia de las integraciones básicas, MCP Browser Agent funciona como un verdadero agente de IA mediante lo siguiente:
Mantener el estado del navegador persistente en múltiples comandos
Captura de registros detallados de la consola para depuración
Almacenamiento de capturas de pantalla para referencia y revisión
Gestión de secuencias de interacción complejas
Proporcionar información detallada sobre errores para la recuperación
Apoyo a operaciones encadenadas para flujos de trabajo complejos
Nombre de la herramienta | Descripción | Parámetros |
| Navegar a una URL |
|
| Captura de pantalla |
|
| Elemento de clic |
|
| Completar formulario de entrada |
|
| Seleccione la opción desplegable |
|
| Pase el cursor sobre el elemento |
|
| Ejecutar JavaScript |
|
Nombre de la herramienta | Descripción | Parámetros |
| Solicitud GET |
|
| Solicitud POST |
|
| Solicitud PUT |
|
| Solicitud de PATCH |
|
| Solicitud DELETE |
|
El agente del navegador MCP expone los siguientes recursos:
browser://logs - Acceder a los registros de la consola del navegador
screenshot://[name] - Acceder a capturas de pantalla por nombre
A continuación se muestran algunos ejemplos realistas de cómo utilizar el agente de navegador MCP con Claude:
Navigate to the Google homepage at https://www.google.comTake a screenshot of the current page and name it "google-homepage"Type "weather forecast" in the search boxNavigate to https://www.wikipedia.org and search for "Model Context Protocol"Go to https://the-internet.herokuapp.com/dropdown and select the option "Option 1" from the dropdownNavigate to https://the-internet.herokuapp.com/login and fill in the username field with "tomsmith" and the password field with "SuperSecretPassword!"Go to https://the-internet.herokuapp.com/login, fill in the username and password fields, then click the login buttonGo to https://example.com and execute a JavaScript script to return the page titleNavigate to https://www.google.com and execute a JavaScript script to count the number of links on the pagePerform a GET request to https://jsonplaceholder.typicode.com/todos/1Make a POST request to https://jsonplaceholder.typicode.com/posts with appropriate JSON dataEstos ejemplos representan las capacidades reales del Agente de Navegador MCP y son más realistas en cuanto a lo que puede lograr en su estado actual.
Si ve el error "Agente del navegador MCP: Servidor desconectado" en Claude Desktop:
Verifique que el servidor esté ejecutándose :
Abra una terminal y ejecute manualmente node dist/index.js desde el directorio del proyecto
Si el servidor se inicia correctamente, utilice Claude mientras mantiene esta terminal abierta
Comprueba tu configuración :
Asegúrese de que la ruta absoluta en claude_desktop_config.json sea correcta para su sistema
Verifique nuevamente que haya utilizado barras invertidas dobles ( \\ ) para las rutas de Windows
Verifique que esté utilizando la ruta completa desde la raíz de su sistema de archivos
Si el navegador no se inicia o no lo ves:
Comprueba si el navegador especificado está instalado
Verifique que tenga el navegador (Chrome, Firefox, Edge o Safari/WebKit) instalado en su sistema
Los controladores del navegador son gestionados automáticamente por Playwright
Reinicie el servidor y Claude Desktop
Elimine cualquier proceso de nodo existente que pueda estar ejecutando el servidor
Reinicie Claude Desktop para establecer una nueva conexión
Existen problemas conocidos con los navegadores Chromium y Chrome donde el proceso a veces no finaliza correctamente después de su uso. Si experimenta este problema:
Cerrar manualmente el proceso del navegador :
Windows : Presione Ctrl+Shift+Esc para abrir el Administrador de tareas, busque el proceso de Chrome/Chromium y finalícelo
macOS : Abra el Monitor de actividad (Aplicaciones > Utilidades > Monitor de actividad), busque el proceso Chrome/Chromium y haga clic en la X para finalizarlo
Linux : ejecute ps aux | grep chrome o ps aux | grep chromium para encontrar el proceso, luego kill <PID> para finalizarlo
Nota sobre la compatibilidad del navegador :
Este problema se ha observado principalmente con Chromium y Chrome.
Los navegadores integrados de Firefox y Playwright no suelen experimentar este problema.
[!PRECAUCIÓN] Esta integración de MCP se basa en Playwright, que presenta problemas y errores conocidos que pueden afectar su funcionamiento. Por favor, reporte cualquier problema que encuentre con la automatización del navegador a la sección de problemas de GitHub de Playwright . El equipo de Playwright trabaja continuamente para solucionar estos problemas, pero este agente proporciona la base para las funciones de automatización del navegador con Claude Desktop a pesar de estas limitaciones.
src/index.ts : Punto de entrada principal e inicialización del servidor MCP
src/tools.ts : Esquemas y registro de herramientas
src/handlers.ts : controladores de solicitudes MCP para herramientas y recursos
src/executor.ts : Lógica de implementación de herramientas usando Playwright
npm run buildnpm run watchEl proyecto incluye pruebas para verificar la funcionalidad principal y el manejo del navegador.
npm test # Run tests
npm run test:watch # Watch mode
npm run test:coverage # Coverage reportLas pruebas verifican la integridad de la configuración, las funciones de automatización del navegador, la gestión de errores y la limpieza de procesos. El conjunto de pruebas se centra especialmente en garantizar la correcta gestión de los procesos del navegador debido a problemas conocidos con la finalización de Chrome/Chromium.
[!IMPORTANTE] Esta integración de MCP proporciona a Claude funciones de control autónomo del navegador. Consulte nuestra Política de Seguridad para obtener información importante sobre usos prohibidos, implicaciones de seguridad y prácticas recomendadas.
El Agente de Navegador MCP está diseñado para tareas de automatización legítimas, pero podría ser objeto de un uso indebido. Los usuarios son responsables de garantizar que su uso cumpla con todas las leyes, términos de servicio y directrices éticas aplicables. Consulte nuestra Política de Seguridad detallada para obtener más información.
¡Agradecemos sus contribuciones al Agente del Navegador MCP! Aquí hay algunas áreas en las que puede colaborar:
Agregar nuevas capacidades de automatización del navegador
Mejorar la gestión y recuperación de errores
Mejorar la captura de pantalla y la gestión de recursos
Creación de flujos de trabajo y ejemplos útiles
Optimización del rendimiento para operaciones complejas
Este proyecto está licenciado bajo la Licencia Pública de Mozilla 2.0: consulte el archivo de LICENCIA para obtener más detalles.
Perform a DELETE request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the action without disclosing side effects, idempotency, authentication needs, rate limits, or return format. This is minimal for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though slightly more context could be included without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the basic action but omits expected return values, error conditions, or usage scope, leaving the description marginally adequate.
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 descriptive parameter names (url, headers). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a DELETE request to an API endpoint, using a specific verb and resource that distinguishes it from sibling tools (api_get, api_patch, etc.) which handle other HTTP methods.
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 api_get or api_post. The description merely repeats the method, missing explicit when/when-not context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a GET request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention that GET is typically safe and idempotent, how errors are handled, or whether redirects are followed.
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 unnecessary words. It efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks information about return values, error handling, authentication requirements, or default behavior. The description is too minimal for an agent to use confidently.
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 both parameters. The tool description adds no extra meaning beyond the schema, so 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 'Perform a GET request to an API endpoint', which identifies the HTTP method and the action. It distinguishes from sibling tools like api_post and api_delete by the method name, but lacks mention of read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. The description does not specify that GET should be used for retrieving data, nor does it mention alternatives for modifying or deleting resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a PATCH request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| data | Yes | Request body data (JSON string) | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it performs a PATCH request, implying mutation, but does not disclose side effects, authentication needs, rate limits, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. However, it is very brief and could benefit from additional context without becoming verbose.
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 is incomplete given the tool's complexity. No output schema exists, and the description does not explain return values or error handling. Sibling tools suggest it is part of an HTTP client set, but the description lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add any additional meaning beyond what is in the input 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 it performs a PATCH request to an API endpoint, which is a specific verb and resource. This distinguishes it from sibling tools like api_get, api_post, etc.
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 other HTTP methods (e.g., POST, PUT) or alternatives. The context signals show siblings, but the description offers no differentiation advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a POST request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| data | Yes | Request body data (JSON string) | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It fails to mention typical POST behavior (resource creation), data validation, or error handling.
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?
Single sentence is concise and front-loaded, but it is too brief and lacks substance for a practical tool description.
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 HTTP tool, description should mention typical use (e.g., 'sends data to URL'). Schema covers parameters but context 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% (all parameters described), so baseline is 3. Description adds no additional meaning 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?
Description states 'POST request' verb and 'API endpoint' resource, clearly distinguishing from sibling tools like api_get, api_put, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no mention of prerequisites or context such as authentication or data format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a PUT request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| data | Yes | Request body data (JSON string) | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'PUT request' implying mutation, but omits critical details like idempotency, side effects, authentication needs, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but does not add meaningful content beyond the tool name; minimal but not wasteful.
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 and no behavioral details; for a tool with 3 parameters and nested objects, the description is insufficient to fully understand usage and return values.
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 3 parameters with descriptions; description adds no extra meaning beyond what schema already provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Perform a PUT request') and resource ('API endpoint'), but lacks differentiation from sibling tools like api_patch or api_post, which perform similar HTTP methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use PUT versus other HTTP methods (e.g., PATCH for partial updates, POST for creation). Does not mention idempotency or replacement semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic action, such as potential side effects (e.g., navigation, page changes) or element visibility requirements. No annotations exist to compensate for this lack of detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately sized for a simple action, though it could benefit from slight elaboration without becoming verbose.
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 sibling tools and the single parameter, the description is incomplete. It fails to mention crucial context like element visibility, clicks causing navigation, or waiting behavior, leaving the agent with insufficient information.
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 fully describes the 'selector' parameter with a clear definition. The description adds no extra meaning beyond the schema, which is acceptable given 100% coverage, but it does not enhance understanding.
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 ('Click an element') and the resource ('on the page'), distinguishing it from sibling tools like browser_fill or browser_hover. However, it could benefit from specifying that it operates within the current page context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to click vs. hover, or prerequisites like page navigation. The description lacks context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the browser context
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions script execution but omits critical details: return value, side effects, permissions, sandboxing, or error handling. This is insufficient for a potentially powerful tool.
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 unnecessary words. It is optimally concise.
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 no output schema, so the description should explain return values or behavior. It does not. Additionally, it lacks details on execution context (e.g., async support, timeout). This leaves the agent underinformed.
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 single required parameter 'script' has a description in the schema. The tool description adds no additional meaning beyond what the schema already provides, making it adequate but not additive.
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 'Execute JavaScript in the browser context' clearly states the action and resource. It is specific and distinct from sibling tools like browser_click or api_get.
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 (e.g., browser_navigate or API calls). An agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a form input with text
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Text to enter in the field | |
| selector | Yes | CSS selector for input field |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral details, but it only says 'fill' without specifying whether it overwrites existing text, waits for elements, or handles disabled fields. This leaves significant behavioral ambiguity.
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, front-loading the action. However, it could be slightly expanded with useful context while remaining brief.
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 (2 params, no output schema), the description is adequate but lacks details on behavior like clearing the field or submission. Sibling tools exist for other form actions, but no comparative guidance is provided.
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?
Input schema covers 100% of parameters with descriptions (selector and value), so baseline is 3. The description adds no additional semantic information 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 'Fill a form input with text' clearly states the action (fill) and the target (form input), distinguishing it from sibling tools like browser_click or browser_select which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_evaluate for setting values or browser_click for activation. There is no mention of prerequisites like element visibility or state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to hover over |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'hover over an element' without explaining whether it triggers JavaScript events, waits for any transitions, or is safe. Essential behavioral context is missing.
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 very concise at 6 words and front-loaded. It is not verbose, but the brevity may sacrifice necessary detail. It earns its place but could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description is incomplete. It does not mention the return value (likely void or success), side effects, or behavior after hovering. Sibling tools suggest a sequence of actions, but this tool's role is under-described.
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 a single parameter 'selector' described as 'CSS selector for element to hover over'. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover over an element on the page' clearly states the action (hover) and target (element on page). It differentiates from siblings like browser_click and browser_fill. However, it could be more specific about the effect (e.g., triggering hover state) but is not a tautology.
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_click or browser_evaluate. The description lacks any context about prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of the current page or a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| mask | No | Selectors for elements to mask | |
| name | Yes | Identifier for the screenshot | |
| fullPage | No | Capture full page height | |
| savePath | No | Path to save screenshot (default: user's Downloads folder) | |
| selector | No | CSS selector for element to capture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the capture affects the page state, any authorization requirements, or rate limits. It only states the action, leaving the agent without important context about side effects or constraints.
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 well-formed sentence that directly states the tool's purpose. It wastes no words, though it could benefit from slightly more detail without becoming verbose.
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 is brief and lacks context about return values (e.g., image path), default behavior, or how the tool interacts with other browser tools. Given the five parameters and no output schema, the description should provide more operational context to be fully 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?
Since schema description coverage is 100%, the baseline is 3. The description does not add additional meaning beyond the parameter names and schema descriptions; for example, it doesn't explain when to use fullPage or mask options more concretely.
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 captures a screenshot of the current page or a specific element, which is a specific verb-resource combination. It distinguishes itself from sibling tools like browser_navigate or browser_click by focusing on capture rather than navigation or element interaction.
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 the tool is used when a screenshot is needed, but it provides no explicit guidance on when to use it versus alternative methods (e.g., browser_evaluate for custom captures) or any exclusions (e.g., not for video capture).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option from a dropdown menu
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Value or label to select | |
| selector | Yes | CSS selector for select element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it waits for options to load, supports custom dropdowns, triggers events, or requires scrolling. The description is too minimal to inform the agent of important behaviors.
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 is front-loaded. However, it sacrifices completeness for brevity. It earns a 4 for being efficient, but could include more key details.
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 no annotations or output schema exist, the description is insufficiently complete. It does not explain return values, constraints, or behavior for complex dropdowns, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters (selector and value) with 100% coverage. The description adds no additional meaning beyond the schema, so 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 it selects an option from a dropdown menu, using a specific verb and resource. It distinguishes from sibling tools like browser_fill (text input) and browser_click (clicking), though it could be more precise by specifying HTML <select> elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., browser_click for custom dropdowns) or any prerequisites. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the browser's viewport size and scale factor
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | Viewport width in pixels | |
| height | No | Viewport height in pixels | |
| deviceScaleFactor | No | Device scale factor (affects how content is scaled) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It only states what the tool changes, but not side effects (e.g., impact on screenshots, persistence across navigation). Lacks important context for a mutation tool.
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?
Single sentence, no fluff. Every word is relevant. Excellent conciseness.
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?
Adequately describes the core function, but lacks details on required fields, defaults, or behavioral context. Acceptable for a simple tool, but could be more 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?
Schema coverage is 100%, with meaningful descriptions for each parameter. The description adds no extra meaning beyond the schema, justifying the baseline score.
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 clearly states the action 'Change' and the target 'browser's viewport size and scale factor'. It is specific and distinct from sibling tools like browser_navigate or browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided. The description implies usage for adjusting viewport, but does not mention alternatives or exclusions. Minimal viable score.
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.
v1.0.0api_deleteapi_getapi_patchapi_postapi_putbrowser_clickbrowser_evaluatebrowser_fillbrowser_hoverbrowser_navigatebrowser_screenshotbrowser_selectbrowser_set_viewportScored across 13 tools
Each tool has a clearly distinct purpose: API tools are differentiated by HTTP method, and browser tools cover unique interactions like clicking, hovering, filling, etc. No two tools overlap in function.
All tools follow a consistent '<domain>_<action>' pattern, with 'api_' prefix for HTTP methods and 'browser_' prefix for browser actions. Naming is unambiguous and predictable.
13 tools is well-scoped for a browser automation and API testing server. Each tool covers a fundamental operation without unnecessary bloat or gaps.
Core browser interactions (navigation, clicking, form filling, selecting, screenshot) and all major HTTP methods are covered. Minor omissions like file upload or wait-for-element are acceptable for this scope.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
