en es ja ko zh

MCP Web Browser Server

Name: MCP Web Browser Server
Author: random-robbie

by random-robbie

Overview Schema Source Related Servers Discussions Admin

Python

Local

MCP 웹 브라우저 서버

Playwright가 제공하는 MCP(Model Context Protocol)를 위한 고급 웹 브라우징 서버로, 유연하고 안전한 API를 통해 헤드리스 브라우저 상호작용을 지원합니다.

🌐 특징

헤드리스 웹 브라우징 : SSL 인증서 검증 우회를 통해 모든 웹사이트 탐색
전체 페이지 콘텐츠 추출 : 동적으로 로드된 JavaScript를 포함한 전체 HTML 콘텐츠를 검색합니다.
다중 탭 지원 : 여러 브라우저 탭을 만들고, 관리하고, 전환합니다.
고급 웹 상호작용 도구 :
- 텍스트 콘텐츠 추출
- 페이지 요소 클릭
- 양식 필드에 텍스트 입력
- 스크린샷 캡처
- 필터링 기능을 사용하여 페이지 링크 추출
- 어느 방향으로든 페이지를 스크롤하세요
- 페이지에서 JavaScript 실행
- 페이지 새로 고침
- 탐색이 완료될 때까지 기다리세요
리소스 관리 : 비활성 후 사용되지 않는 리소스를 자동으로 정리합니다.
향상된 페이지 정보 : 현재 페이지에 대한 자세한 메타데이터를 가져옵니다.

Related MCP server: Cloudflare Playwright MCP

🚀 빠른 시작

필수 조건

파이썬 3.10+
MCP SDK
극작가

설치

지엑스피1

Claude Desktop 구성

claude_desktop_config.json 에 다음을 추가하세요:

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

💡 사용 예시

기본 웹 탐색

# 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")

웹 상호작용

# 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")

스크린샷 캡처

# 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")

링크 추출

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

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

멀티탭 브라우징

# 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)

고급 상호작용

# 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)

🛡️ 보안 기능

SSL 인증서 유효성 검사 우회
안전한 브라우저 컨텍스트 관리
사용자 정의 사용자 에이전트 구성
오류 처리 및 포괄적인 로깅
구성 가능한 시간 초과 설정
CSP 바이패스 제어
쿠키 도용 방지

🔧 문제 해결

일반적인 문제

SSL 인증서 오류 : 자동으로 우회됨
느린 페이지 로드 : browse_to() 메서드에서 시간 초과 조정
요소를 찾을 수 없음 : 선택기를 주의 깊게 확인하세요
브라우저 리소스 사용량 : 비활성 기간 후 자동 정리

벌채 반출

모든 중요한 이벤트는 자세한 정보와 함께 기록되어 디버깅이 쉽습니다.

📋 도구 매개변수

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

url : 이동할 웹사이트
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

selector : 특정 콘텐츠를 추출하는 선택적 CSS 선택기
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

selector : 클릭할 요소의 CSS 선택자
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

full_page : 전체 페이지 스크린샷 캡처
selector : 스크린샷을 찍을 선택 요소
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

filter_pattern : 링크를 필터링하기 위한 선택적 텍스트 패턴
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

selector : 입력 요소의 CSS 선택자
text : 입력할 텍스트
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

url : 새 탭에서 이동할 선택적 URL
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

tab_id : 전환할 탭의 ID
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

`list_tabs(context: Optional[Any] = None)`

context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

tab_id : 닫을 탭의 선택적 ID(기본값은 현재 탭)
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

`refresh_page(context: Optional[Any] = None)`

context : 선택적 컨텍스트 객체(현재 사용되지 않음)

`get_page_info(context: Optional[Any] = None)`

context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

direction : 스크롤 방향('위', '아래', '왼쪽', '오른쪽')
amount : 스크롤할 양('페이지', '절반' 또는 숫자)
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

timeout_ms : 대기할 최대 시간(밀리초)
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

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

script : 실행할 JavaScript 코드
context : 선택적 컨텍스트 객체(현재 사용되지 않음)

🤝 기여하기

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

개발 설정

# 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]

📄 라이센스

MIT 라이센스

🔗 관련 프로젝트

💬 지원

문제가 있거나 질문이 있으시면 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

Name	Required	Description	Default
`url`	Yes
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`selector`	Yes
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`selector`	No
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`full_page`	No
`selector`	No
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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

Name	Required	Description	Default
`selector`	Yes
`text`	Yes
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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.

6 tool updatesAug 18, 2025
- First observedbrowse_to
- First observedclick_element
- First observedextract_text_content
- First observedget_page_links
- First observedget_page_screenshots
- First observedinput_text

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-04-18 11:45 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

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

browser-forest A
com.browserforest
Undetectable cloud browser sessions for AI agents and scrapers. Navigate, extract, click, captcha.
Browser Automation Web Scraping Agent Orchestration
91
browser-automation C
io.github.DataLeadsPRO
Programmatic headless browser sessions: create, interact, browse, and extract - rendered in a real
Browser Automation Web Scraping
51
render-mcp A
io.github.RodRomer
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Browser Automation Testing & QA Tools
61
ImRonAI-mcp-server-browserbase
ai.smithery
Automate cloud browsers to navigate websites, interact with elements, and extract structured data.…
Browser Automation Web Scraping App Automation
2

Related MCP Servers

Playwright MCP Server
Browser Automation Web Scraping Agent Orchestration
lebrodus
A
license
B
quality
D
maintenance
A server that enables browser automation using Playwright, allowing interaction with web pages, capturing screenshots, and executing JavaScript in a browser environment through LLMs.
Updated 2 years ago (2025-01-03 06:24 UTC)
12
15,344 npm
1
MIT
Cloudflare Playwright MCP
Browser Automation Web Scraping
sent3nal
F
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.
Updated a year ago (2025-06-25 01:27 UTC)
-
Playwright MCP Server
Browser Automation Web Scraping
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.
Updated 9 months ago (2025-12-17 13:17 UTC)
5 npm
MIT
Browser MCP
Browser Automation Web Scraping
blink-new
A
license
Not graded
quality
D
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.
Updated 8 months ago (2026-01-29 00:41 UTC)
1
MIT

MCP 웹 브라우저 서버

🌐 특징

🚀 빠른 시작

필수 조건

설치

Claude Desktop 구성

💡 사용 예시

기본 웹 탐색

웹 상호작용

스크린샷 캡처

링크 추출

멀티탭 브라우징

고급 상호작용

🛡️ 보안 기능

🔧 문제 해결

일반적인 문제

벌채 반출

📋 도구 매개변수

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

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

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

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

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

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

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

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

list_tabs(context: Optional[Any] = None)

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

refresh_page(context: Optional[Any] = None)

get_page_info(context: Optional[Any] = None)

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

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

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

🤝 기여하기

개발 설정

📄 라이센스

🔗 관련 프로젝트

💬 지원

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

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

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

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

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

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

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

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

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

`list_tabs(context: Optional[Any] = None)`

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

`refresh_page(context: Optional[Any] = None)`

`get_page_info(context: Optional[Any] = None)`

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

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

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