Skip to main content
Glama
enesjakozh
random-robbie

MCP Web Browser Server

by random-robbie
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Servidor de navegador web MCP

Un servidor de navegación web avanzado para el Protocolo de Contexto de Modelo (MCP) impulsado por Playwright, que permite interacciones de navegador sin cabeza a través de una API flexible y segura.

🌐 Características

  • Navegación web sin interfaz gráfica : navegue a cualquier sitio web sin necesidad de validar el certificado SSL.

  • Extracción de contenido de página completa : recupera contenido HTML completo, incluido JavaScript cargado dinámicamente

  • Compatibilidad con múltiples pestañas : cree, administre y cambie entre múltiples pestañas del navegador

  • Herramientas avanzadas de interacción web :

    • Extraer contenido de texto

    • Haga clic en los elementos de la página

    • Introducir texto en los campos de formulario

    • Capturar capturas de pantalla

    • Extraer enlaces de páginas con capacidades de filtrado

    • Desplácese por las páginas en cualquier dirección

    • Ejecutar JavaScript en las páginas

    • Actualizar páginas

    • Espere a que se complete la navegación

  • Gestión de recursos : Limpieza automática de recursos no utilizados después de la inactividad

  • Información de página mejorada : obtenga metadatos detallados sobre la página actual

Related MCP server: Cloudflare Playwright MCP

🚀 Inicio rápido

Prerrequisitos

  • Python 3.10+

  • Kit de desarrollo de software de MCP

  • Dramaturgo

Instalación

# Install MCP and Playwright
pip install mcp playwright

# Install browser dependencies
playwright install

Configuración para Claude Desktop

Añade a tu claude_desktop_config.json :

{
  "mcpServers": {
    "web-browser": {
      "command": "python",
      "args": [
        "/path/to/your/server.py"
      ]
    }
  }
}

💡 Ejemplos de uso

Navegación web básica

# Browse to a website
page_content = browse_to("https://example.com")

# Extract page text
text_content = extract_text_content()

# Extract text from a specific element
title_text = extract_text_content("h1.title")

Interacción web

# Navigate to a page
browse_to("https://example.com/login")

# Input text into a form
input_text("#username", "your_username")
input_text("#password", "your_password")

# Click a login button
click_element("#login-button")

Captura de pantalla

# Capture full page screenshot
full_page_screenshot = get_page_screenshots(full_page=True)

# Capture specific element screenshot
element_screenshot = get_page_screenshots(selector="#main-content")

Extracción de enlaces

# Get all links on the page
page_links = get_page_links()

# Get links matching a pattern
filtered_links = get_page_links(filter_pattern="contact")

Navegación con múltiples pestañas

# Create a new tab
tab_id = create_new_tab("https://example.com")

# Create another tab
another_tab_id = create_new_tab("https://example.org")

# List all open tabs
tabs = list_tabs()

# Switch between tabs
switch_tab(tab_id)

# Close a tab
close_tab(another_tab_id)

Interacciones avanzadas

# Scroll the page
scroll_page(direction="down", amount="page")

# Execute JavaScript on the page
result = execute_javascript("return document.title")

# Get detailed page information
page_info = get_page_info()

# Refresh the current page
refresh_page()

# Wait for navigation to complete
wait_for_navigation(timeout_ms=5000)

🛡️ Funciones de seguridad

  • Omisión de la validación del certificado SSL

  • Gestión segura del contexto del navegador

  • Configuración personalizada del agente de usuario

  • Manejo de errores y registro completo

  • Configuraciones de tiempo de espera configurables

  • Control de derivación de CSP

  • Protección contra el robo de cookies

🔧 Solución de problemas

Problemas comunes

  • Errores del certificado SSL : se omiten automáticamente

  • Carga de página lenta : ajuste el tiempo de espera en el método browse_to()

  • Elemento no encontrado : Verifique los selectores cuidadosamente

  • Uso de recursos del navegador : limpieza automática después de un período de inactividad

Explotación florestal

Todos los eventos importantes se registran con información detallada para una fácil depuración.

📋 Parámetros de la herramienta

browse_to(url: str, context: Optional[Any] = None)

  • url : Sitio web al que navegar

  • context : objeto de contexto opcional (actualmente sin uso)

extract_text_content(selector: Optional[str] = None, context: Optional[Any] = None)

  • selector : Selector CSS opcional para extraer contenido específico

  • context : objeto de contexto opcional (actualmente sin uso)

click_element(selector: str, context: Optional[Any] = None)

  • selector : selector CSS del elemento en el que hacer clic

  • context : objeto de contexto opcional (actualmente sin uso)

get_page_screenshots(full_page: bool = False, selector: Optional[str] = None, context: Optional[Any] = None)

  • full_page : Capturar una captura de pantalla de toda la página

  • selector : Elemento opcional para captura de pantalla

  • context : objeto de contexto opcional (actualmente sin uso)

get_page_links(filter_pattern: Optional[str] = None, context: Optional[Any] = None)

  • filter_pattern : Patrón de texto opcional para filtrar enlaces

  • context : objeto de contexto opcional (actualmente sin uso)

input_text(selector: str, text: str, context: Optional[Any] = None)

  • selector : selector CSS del elemento de entrada

  • text : Texto a introducir

  • context : objeto de contexto opcional (actualmente sin uso)

create_new_tab(url: Optional[str] = None, context: Optional[Any] = None)

  • url : URL opcional para navegar en la nueva pestaña

  • context : objeto de contexto opcional (actualmente sin uso)

switch_tab(tab_id: str, context: Optional[Any] = None)

  • tab_id : ID de la pestaña a la que cambiar

  • context : objeto de contexto opcional (actualmente sin uso)

list_tabs(context: Optional[Any] = None)

  • context : objeto de contexto opcional (actualmente sin uso)

close_tab(tab_id: Optional[str] = None, context: Optional[Any] = None)

  • tab_id : ID opcional de la pestaña que se cerrará (predeterminado: la pestaña actual)

  • context : objeto de contexto opcional (actualmente sin uso)

refresh_page(context: Optional[Any] = None)

  • context : objeto de contexto opcional (actualmente sin uso)

get_page_info(context: Optional[Any] = None)

  • context : objeto de contexto opcional (actualmente sin uso)

scroll_page(direction: str = "down", amount: str = "page", context: Optional[Any] = None)

  • direction : Dirección para desplazarse ('arriba', 'abajo', 'izquierda', 'derecha')

  • amount : Cantidad a desplazar ('página', 'mitad' o un número)

  • context : objeto de contexto opcional (actualmente sin uso)

wait_for_navigation(timeout_ms: int = 10000, context: Optional[Any] = None)

  • timeout_ms : Tiempo máximo de espera en milisegundos

  • context : objeto de contexto opcional (actualmente sin uso)

execute_javascript(script: str, context: Optional[Any] = None)

  • script : código JavaScript para ejecutar

  • context : objeto de contexto opcional (actualmente sin uso)

🤝 Contribuyendo

¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.

Configuración de desarrollo

# Clone the repository
git clone https://github.com/random-robbie/mcp-web-browser.git

# Create virtual environment
python -m venv venv
source venv/bin/activate  # On Windows use `venv\Scripts\activate`

# Install dependencies
pip install -e .[dev]

📄 Licencia

Licencia MIT

🔗 Proyectos relacionados

💬 Soporte

Si tiene problemas o preguntas, abra un problema en GitHub.

Available Tools

6 tools
browse_toA
Navigate to a specific URL and return the page's HTML content.

Args:
    url: The full URL to navigate to
    context: Optional context object for logging (ignored)

Returns:
    The full HTML content of the page
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
contextNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions navigation and returning HTML content, but fails to describe critical behaviors such as timeouts, error handling, JavaScript execution, or network conditions. This leaves significant gaps for a tool that interacts with external resources.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by structured sections for arguments and returns. Every sentence adds value without redundancy, making it efficient and easy to parse. The formatting enhances readability without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (external navigation) and lack of annotations, the description is moderately complete but has gaps. It explains the return value, and an output schema exists, so return details aren't needed. However, it omits behavioral aspects like performance or security considerations, which are important for such a tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the 'url' parameter's purpose ('full URL to navigate to') and notes that 'context' is optional and ignored for logging, adding meaningful semantics beyond the bare schema. However, it doesn't detail URL format requirements or context structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Navigate to a specific URL') and resource ('page's HTML content'), distinguishing it from siblings like click_element or input_text that perform different browser interactions. It precisely defines the tool's function without being vague or tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving HTML content from URLs, which provides clear context, but it doesn't explicitly state when to use this tool versus alternatives like get_page_links or extract_text_content. No misleading guidance is present, but it lacks explicit exclusions or named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

click_elementC
Click an element on the current page.

Args:
    selector: CSS selector for the element to click
    context: Optional context object for logging (ignored)

Returns:
    Confirmation message or error details
ParametersJSON Schema
NameRequiredDescriptionDefault
selectorYes
contextNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action is 'click' but doesn't mention what happens if the element isn't found, if the page needs to be loaded first, if there are timing considerations, or what errors might occur. This leaves significant gaps for a tool that performs UI interactions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with a clear purpose statement followed by parameter and return value sections. Each sentence adds value, though the 'context' explanation could be more precise about why it's included if ignored.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this is a UI interaction tool with no annotations and 2 parameters (one with 0% schema coverage), the description is minimally adequate. It explains the basic purpose and parameters but lacks crucial behavioral context about error conditions, prerequisites, and interaction patterns. The presence of an output schema helps but doesn't fully compensate for missing operational details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains that 'selector' is a 'CSS selector for the element to click' and that 'context' is 'optional... for logging (ignored)', which adds meaningful semantics beyond the bare schema. However, it doesn't provide examples of valid selectors or explain what 'ignored' means operationally.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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 target ('on the current page'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from potential sibling tools like 'input_text' or 'browse_to' that might also interact with page elements, missing full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'input_text' for text entry or 'browse_to' for navigation. It mentions the context parameter is 'ignored' but doesn't explain when this tool is appropriate versus other interaction methods.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

extract_text_contentA
Extract text content from the current page, optionally using a CSS selector.

Args:
    selector: Optional CSS selector to target specific elements
    context: Optional context object for logging (ignored)

Returns:
    Extracted text content
ParametersJSON Schema
NameRequiredDescriptionDefault
selectorNo
contextNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the tool extracts text and that 'context' is ignored, but lacks details on behavioral traits such as error handling (e.g., if selector fails), performance (e.g., timeouts), or output format specifics (though output schema exists). It doesn't disclose permissions, rate limits, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. Every sentence earns its place by explaining parameters and return value efficiently, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 parameters with 0% schema coverage, no annotations, and an output schema (which handles return values), the description is mostly complete. It covers purpose and parameter semantics adequately but lacks behavioral details like error cases or performance constraints, which would be beneficial for a tool interacting with web pages.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'selector' as 'Optional CSS selector to target specific elements' and 'context' as 'Optional context object for logging (ignored)', which clarifies their purposes beyond the schema's basic types. However, it doesn't detail selector syntax or context structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'extract' and resource 'text content from the current page', specifying it can optionally use a CSS selector. This distinguishes it from siblings like browse_to (navigation), click_element (interaction), get_page_links (link extraction), get_page_screenshots (visual capture), and input_text (text entry).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by mentioning 'optionally using a CSS selector' and 'from the current page', suggesting it's for extracting text after navigation. However, it doesn't explicitly state when to use this versus alternatives like get_page_links (for links) or when not to use it (e.g., for non-text content). No explicit alternatives or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_page_linksB
Extract all links from the current page.

Args:
    context: Optional context object for logging (ignored)

Returns:
    List of links found on the page
ParametersJSON Schema
NameRequiredDescriptionDefault
contextNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Extract all links') but lacks critical details: whether this requires page interaction, if it works on any loaded page, potential rate limits, error handling, or what 'current page' means in context. The return format is mentioned but without specifics like link structure or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise and well-structured: a clear purpose statement followed by brief, bullet-like sections for Args and Returns. Every sentence earns its place with no redundant information, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (extracting links from a page), no annotations, and an output schema present (which handles return values), the description is minimally adequate. It covers the basic purpose and parameter semantics but lacks behavioral context and usage guidelines, leaving gaps for an agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaningful context for the single parameter: it explains that 'context' is optional and for logging purposes only, and explicitly states it's ignored. Since schema description coverage is 0% and there's only one parameter, this adequately compensates, though it doesn't detail logging specifics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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 a specific verb ('Extract') and resource ('all links from the current page'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'extract_text_content' or 'get_page_screenshots', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to be on a page first), compare to siblings like 'extract_text_content' for non-link content, or specify use cases (e.g., for navigation vs. analysis).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_page_screenshotsA
Capture screenshot of the current page.

Args:
    full_page: Whether to capture the entire page or just the viewport
    selector: Optional CSS selector to screenshot a specific element
    context: Optional context object for logging (ignored)

Returns:
    Base64 encoded screenshot image
ParametersJSON Schema
NameRequiredDescriptionDefault
full_pageNo
selectorNo
contextNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that the tool captures screenshots and returns base64 encoded images, but doesn't mention behavioral aspects like whether it requires page load completion, handles dynamic content, has size limitations, or potential performance impacts. The 'context' parameter is noted as 'ignored', which is useful transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement followed by organized Args and Returns sections. Every sentence adds value: the first states the action, and the parameter explanations are necessary for understanding usage. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (screenshot capture with options), no annotations, and an output schema (implied by 'Returns' statement), the description is reasonably complete. It covers purpose, parameters, and return format. However, it lacks some behavioral context like prerequisites (e.g., page must be loaded) or limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well by explaining all three parameters: 'full_page' (entire page vs viewport), 'selector' (CSS selector for specific element), and 'context' (ignored for logging). This adds meaningful semantics beyond the bare schema, though it doesn't provide format examples or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Capture screenshot') and resource ('of the current page'), distinguishing it from sibling tools like 'get_page_links' or 'extract_text_content' which handle different types of page content extraction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through the parameter explanations (e.g., 'Whether to capture the entire page or just the viewport'), but doesn't explicitly state when to use this tool versus alternatives like 'extract_text_content' for text or 'get_page_links' for links. No explicit when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

input_textB
Input text into a specific element on the page.

Args:
    selector: CSS selector for the input element
    text: Text to input
    context: Optional context object for logging (ignored)

Returns:
    Confirmation message
ParametersJSON Schema
NameRequiredDescriptionDefault
selectorYes
textYes
contextNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool inputs text and returns a confirmation, but lacks critical details: whether it simulates typing or sets value directly, if it waits for element visibility, error handling for invalid selectors, or side effects. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise and well-structured. It starts with a clear purpose statement, followed by bullet-point explanations of each parameter and the return value. Every sentence earns its place with no redundant information, making it easy to scan and understand.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, mutation operation) and the presence of an output schema (which covers return values), the description is partially complete. It explains parameters well but lacks behavioral context like error conditions or interaction details. With no annotations, it should do more to guide safe usage, but the output schema reduces the need to describe returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant value beyond the input schema, which has 0% description coverage. It explains that 'selector' is a 'CSS selector for the input element', 'text' is 'Text to input', and 'context' is 'Optional context object for logging (ignored)'. This clarifies parameter purposes and constraints, compensating well for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Input text into a specific element on the page.' This specifies the verb ('input text') and resource ('specific element on the page'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'extract_text_content' or 'click_element', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a page loaded via 'browse_to'), exclusions, or comparisons to other input-related tools. The agent must infer usage from context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updates
    • First observedbrowse_to
    • First observedclick_element
    • First observedextract_text_content
    • First observedget_page_links
    • First observedget_page_screenshots
    • First observedinput_text
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

A3.7/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: navigation, clicking, text extraction, link extraction, screenshot capture, and text input. The descriptions reinforce these distinct functions, making it easy for an agent to select the right tool for each task without confusion.

Naming Consistency4/5

The tools follow a consistent verb_noun or verb_adjective_noun pattern (e.g., browse_to, click_element, extract_text_content), with all names using snake_case. The only minor deviation is 'get_page_links' and 'get_page_screenshots' using 'get' instead of a more specific verb like 'extract', but this is still readable and maintains overall consistency.

Tool Count5/5

With 6 tools, this server is well-scoped for basic web browsing automation, covering essential actions like navigation, interaction, and content extraction. Each tool earns its place without being overly complex or insufficient for the domain, making it manageable and effective for typical use cases.

Completeness4/5

The toolset provides solid coverage for core web browsing tasks, including navigation, interaction (clicking and input), and content extraction (text, links, screenshots). A minor gap is the lack of tools for more advanced actions like form submission, scrolling, or handling pop-ups, but agents can likely work around this with the existing tools for most workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Cloudflare Playwright MCP

    sent3nal
    A
    license
    Not graded
    quality
    C
    maintenance
    A server that enables AI assistants to control a browser through tools, allowing them to perform web automation tasks like navigation, typing, clicking, and taking screenshots.
    Apache 2.0

  • Playwright MCP Server

    Leviathangk
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables browser automation and web scraping with multi-session management, supporting page navigation, element interaction, network request capture, and content extraction across multiple concurrent browser instances.
    6 npm
    MIT

  • Browser MCP

    blink-new
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server for browser automation using Puppeteer that enables AI assistants to navigate web pages, interact with UI elements, and capture screenshots. It supports comprehensive web tasks including form filling, content extraction, and executing custom JavaScript within the browser context.
    2
    MIT

Appeared in Searches