Skip to main content
Glama
enesjakozh
themindmod

Selenium MCP Server

by themindmod
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

셀레늄 MCP 서버

대장간 배지

Selenium을 사용하여 WebDriver 인스턴스와 상호 작용하는 MCP 서버입니다. MCP-Server-Starter 템플릿을 사용하여 빌드되었습니다.

개요

이 서버를 사용하면 AI 에이전트가 Selenium WebDriver를 통해 웹 브라우저 세션을 제어할 수 있어 Model Context Protocol을 통해 웹 스크래핑, 자동 테스트, 양식 작성과 같은 작업이 가능합니다.

Related MCP server: mcp-selenium-python

핵심 구성 요소

  • MCP 서버 : Selenium WebDriver 작업을 MCP 도구로 제공합니다.

  • Selenium WebDriver : 브라우저와 상호작용합니다.

  • MCP 클라이언트 : 노출된 도구를 활용할 수 있는 AI 호스트(Cursor, Claude Desktop 등)입니다.

필수 조건

  • Node.js(v18 이상)

  • npm(v7 이상)

  • WebDriver 실행 파일 (예: ChromeDriver, GeckoDriver)이 시스템의 PATH에 설치되어 사용 가능해야 합니다.

  • 호환되는 웹 브라우저 (예: Chrome, Firefox)

시작하기

  1. 저장소를 복제합니다.

    지엑스피1

  2. 종속성 설치:

    npm install

  3. WebDriver 구성:

    • WebDriver(예: chromedriver )가 설치되어 있고 PATH에 있는지 확인하세요.

    • 필요한 경우 브라우저 옵션이나 WebDriver 경로를 지정하기 위해 src/seleniumService.ts (이 파일을 직접 생성함)를 수정합니다.

  4. 서버를 빌드하세요:

    npm run build

  5. 서버를 실행합니다:

    npm start

    또는 Cursor나 Claude Desktop과 같은 MCP 호스트와 통합할 수 있습니다(아래 통합 섹션 참조).

도구

이 서버는 다음과 같은 도구를 제공합니다.

  • selenium_navigate : 브라우저를 특정 URL로 이동합니다.

  • selenium_findElement : CSS 선택기를 사용하여 페이지에서 요소를 찾습니다.

  • selenium_click : 요소를 클릭합니다.

  • selenium_sendKeys : 키 입력을 요소에 전송합니다.

  • selenium_getPageSource : 현재 페이지 소스 HTML을 검색합니다.

  • (필요에 따라 도구를 더 추가하세요)

TypeScript 구현

서버는 @modelcontextprotocol/sdk 및 selenium-webdriver 라이브러리를 사용합니다.

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { Builder, By, Key, until, WebDriver } from 'selenium-webdriver';

// Basic server setup (details in src/index.ts)
const server = new Server({
  name: "selenium-mcp-server",
  version: "0.1.0",
  capabilities: {
    tools: {}, // Enable tools capability
  }
});

// Selenium WebDriver setup (details in src/seleniumService.ts)
let driver: WebDriver;

async function initializeWebDriver() {
  driver = await new Builder().forBrowser('chrome').build(); // Or 'firefox', etc.
}

// Example tool implementation (details in src/tools/)
server.registerTool('selenium_navigate', {
  description: 'Navigates the browser to a specific URL.',
  inputSchema: { /* ... zod schema ... */ },
  outputSchema: { /* ... zod schema ... */ },
  handler: async (params) => {
    await driver.get(params.url);
    return { success: true };
  }
});

// Connect transport
async function startServer() {
  await initializeWebDriver();
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.log("Selenium MCP Server connected via stdio.");

  // Graceful shutdown
  process.on('SIGINT', async () => {
    console.log("Shutting down WebDriver...");
    if (driver) {
      await driver.quit();
    }
    process.exit(0);
  });
}

startServer();

개발

  • 빌드: npm run build

  • 실행: npm start ( node build/index.js 실행)

  • 린트: npm run lint

  • 형식: npm run format

디버깅

MCP Inspector나 표준 Node.js 디버깅 기술을 사용하세요.

MCP 호스트와의 통합

(Cursor, Claude Desktop, Smithery 등의 원래 README에서 관련 섹션을 유지하고 필요에 따라 경로와 명령을 업데이트합니다)

커서 통합

  1. 서버를 빌드하세요 : npm run build

  2. 커서: Settings > Features > MCP : 새로운 MCP 서버를 추가합니다.

  3. 서버를 등록하세요 :

    • 전송 유형으로 stdio 선택합니다.

    • 이름: Selenium Server (또는 유사한 서버).

    • 명령어: node /path/to/selenium-mcp-server/build/index.js .

  4. 구하다 .

Claude 데스크톱 통합

  1. 서버를 빌드하세요 : npm run build

  2. claude_desktop_config.json수정합니다 :

    {
  "mcpServers": {
    "selenium-mcp-server": {
      "command": "node",
      "args": [
        "/path/to/selenium-mcp-server/build/index.js"
      ]
    }
  }
}

  3. Claude Desktop을 다시 시작합니다 .

모범 사례

  • 유형 안전성과 검증을 위해 TypeScript와 Zod를 사용하세요.

  • 도구를 모듈식으로 유지합니다(예: src/tools/ 에 도구당 하나의 파일).

  • WebDriver 오류를 정상적으로 처리합니다(예: 요소를 찾을 수 없음, 탐색 문제).

  • 적절한 WebDriver 종료를 보장합니다(예: 서버 종료 시 driver.quit() ).

  • 스키마, 오류 처리 및 콘텐츠 유형에 대한 MCP 모범 사례를 따르세요.

자세히 알아보기

크레딧

Seth Rose가 만든 템플릿을 기반으로 :

Available Tools

6 tools
browser_clickC

Perform click on a web page

ParametersJSON Schema
NameRequiredDescriptionDefault
elementYesHuman-readable element description
refYesExact target element reference from the page snapshot

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 but only states the basic action without disclosing behavioral traits. It doesn't mention whether this is a safe operation, what happens on failure (e.g., element not found), if it triggers page navigation, or any side effects like waiting for page loads. The description is minimal and lacks crucial operational context.

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 extremely concise with just four words, front-loading the essential action without any wasted words. Every part of the sentence earns its place by specifying both the action and target.

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

Completeness2/5

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

Given the complexity of a browser interaction tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after the click (e.g., page changes, navigation), error conditions, or how it integrates with sibling tools like 'browser_snapshot' for obtaining element references. For a tool that performs page mutations, more context is needed.

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 100%, so the schema already documents both parameters ('element' as human-readable description and 'ref' as exact target reference). The description adds no additional meaning about these parameters beyond what the schema provides, maintaining the baseline score.

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 ('Perform click') and target ('on a web page'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling interactions like 'browser_type' or 'browser_wait_for' in terms of when clicking is appropriate versus other browser actions.

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 'browser_type' or 'browser_wait_for'. It doesn't mention prerequisites (e.g., needing a page snapshot first) or contextual constraints (e.g., only usable after navigation).

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

browser_navigateC

Navigate to a URL

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to navigate to

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 the full burden of behavioral disclosure. It states the action but omits critical details such as whether navigation is synchronous or asynchronous, error handling (e.g., invalid URLs), side effects (e.g., page reload), or performance implications. This leaves significant gaps in understanding how the tool behaves beyond the basic action.

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 extremely concise at three words, front-loading the core action without any wasted text. Every word ('Navigate to a URL') directly contributes to understanding the tool's purpose, making it efficient and easy to parse.

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

Completeness2/5

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

Given the complexity of browser navigation (which can involve errors, delays, or state changes) and the lack of annotations and output schema, the description is insufficiently complete. It does not address what happens after navigation (e.g., success/failure indicators, page load events), leaving the agent without necessary context for effective use in a workflow.

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?

The input schema has 100% description coverage, with the 'url' parameter clearly documented as 'The URL to navigate to'. The description adds no additional meaning beyond what the schema provides, such as URL format requirements or examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.

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 'Navigate to a URL' clearly states the action (navigate) and target resource (URL), making the purpose immediately understandable. However, it does not differentiate this tool from potential siblings like browser_click or browser_type, which also involve browser interactions but 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.

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 lacks context such as prerequisites (e.g., browser must be open), exclusions (e.g., not for clicking or typing), or comparisons to sibling tools like browser_wait_for, leaving the agent to infer usage from the tool name alone.

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

browser_snapshotB

Capture accessibility snapshot of the current page

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/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 but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, what permissions are needed, how it handles errors, or the format of the snapshot output, which are critical for a tool interacting with a browser.

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 a single, clear sentence with no wasted words, front-loading the key action and target. It's appropriately sized for a simple tool with no parameters.

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

Completeness2/5

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

Given the complexity of browser interactions and lack of annotations or output schema, the description is incomplete. It doesn't explain what an 'accessibility snapshot' entails, how it's returned, or any behavioral constraints, leaving significant gaps for an AI agent to understand tool usage.

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 tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description appropriately doesn't mention parameters, earning a baseline score of 4 for not introducing unnecessary details.

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 ('capture') and target ('accessibility snapshot of the current page'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'browser_take_screenshot', which might capture visual content rather than accessibility data.

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 'browser_take_screenshot' or other browser tools. It lacks context about prerequisites (e.g., needing a page loaded) or exclusions, leaving usage unclear.

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

browser_take_screenshotC

Take a screenshot of the current page

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNoFile name to save the screenshot to
rawNoWhether to return without compression (PNG format)

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 the full burden of behavioral disclosure. It mentions the action but lacks details on permissions needed, file storage location, error handling, or whether it captures the full page or viewport. This leaves significant gaps for an AI agent to understand the tool's behavior.

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 a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't address what the tool returns (e.g., file path, binary data), error conditions, or dependencies like requiring an active browser session, which are critical for a screenshot tool.

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?

The input schema has 100% description coverage, clearly documenting both parameters. The description does not add any additional meaning or context beyond what the schema provides, such as default values or usage examples, so it meets the baseline for high schema coverage.

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 ('take a screenshot') and the target ('current page'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'browser_snapshot' which might have overlapping functionality, preventing 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?

No guidance is provided on when to use this tool versus alternatives such as 'browser_snapshot' or other screenshot-related methods. The description only states what it does, not the context or prerequisites for its use.

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

browser_typeC

Type text into editable element

ParametersJSON Schema
NameRequiredDescriptionDefault
elementYesHuman-readable element description
refYesExact target element reference from the page snapshot
submitNoWhether to submit entered text (press Enter after)
textYesText to type into the element

TDQS

C2.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 full burden for behavioral disclosure. 'Type text into editable element' implies a mutation/write operation but doesn't specify side effects (e.g., whether it triggers events, changes page state, or requires focus). It also omits error conditions (e.g., if element isn't editable) and doesn't describe what happens after typing (e.g., whether it waits for page updates). For a mutation tool with zero annotation coverage, this is inadequate.

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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Type text') and target ('editable element'), making it immediately understandable. Every word earns its place by conveying essential purpose.

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

Completeness2/5

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

Given the tool's complexity (mutation with 4 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain return values, error handling, or behavioral nuances like the 'submit' parameter's effect. For a browser automation tool that modifies page state, more context is needed to ensure safe and correct usage by an agent.

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 100%, with all parameters well-documented in the schema (element, ref, submit, text). The description adds no parameter-specific information beyond implying 'text' is typed and 'element' is editable. Since the schema already provides full descriptions, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to given high schema coverage.

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 'Type text into editable element' clearly states the action (type) and target (editable element), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling interactions like browser_click or browser_wait_for, which might also involve editable elements in different ways.

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 snapshot first), when not to use it (e.g., for non-editable elements), or how it relates to sibling tools like browser_click or browser_submit (if that existed). 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.

browser_wait_forC

Wait for text to appear or disappear or a specified time to pass

ParametersJSON Schema
NameRequiredDescriptionDefault
textNoThe text to wait for
textGoneNoThe text to wait for to disappear
timeNoThe time to wait in seconds

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 but offers minimal behavioral insight. It mentions what the tool does (waiting) but not how it behaves—e.g., timeout behavior, error handling, or interaction with browser state. This leaves critical operational details unspecified for a tool with potential 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 extremely concise—a single sentence that directly states the tool's function without redundancy. Every word contributes to understanding, and it's front-loaded with the core purpose, making it efficient and easy to parse.

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

Completeness2/5

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

Given no annotations, no output schema, and a tool that interacts with dynamic browser state, the description is incomplete. It lacks details on return values, failure modes, or dependencies on other browser tools, leaving gaps for safe and effective use in automation contexts.

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 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying these parameters are used for waiting conditions. It doesn't clarify mutual exclusivity or default behaviors, but the schema already covers basics, meeting the baseline.

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 as waiting for text to appear/disappear or for time to pass, which is specific and actionable. It distinguishes itself from siblings like browser_click or browser_type by focusing on waiting rather than interaction. However, it doesn't explicitly mention browser context, which could slightly improve clarity.

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 specify scenarios where waiting for text is preferable to waiting for time, or when to use this over other browser tools. Without usage context, the agent must infer appropriate applications.

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 updatesv1.0.0
    • First observedbrowser_click
    • First observedbrowser_navigate
    • First observedbrowser_snapshot
    • First observedbrowser_take_screenshot
    • First observedbrowser_type
    • First observedbrowser_wait_for
Deploy Server
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

TDQS

A3.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: clicking, navigating, capturing snapshots, taking screenshots, typing text, and waiting for conditions. The descriptions make it easy to differentiate between them, eliminating any ambiguity in tool selection.

Naming Consistency5/5

All tools follow a consistent 'browser_' prefix with descriptive action names (e.g., click, navigate, snapshot). This uniform snake_case pattern makes the tool set predictable and easy to understand, enhancing usability for agents.

Tool Count5/5

With 6 tools, the server is well-scoped for web automation tasks. Each tool serves a specific, essential function in the Selenium domain, avoiding bloat while covering core interactions like navigation, input, and monitoring.

Completeness4/5

The tool set covers key web automation actions (navigation, interaction, monitoring), but lacks some common operations like form submission, element selection, or handling alerts. However, agents can work around these gaps using existing tools, making it mostly complete for basic workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • openmcp

    openmcp-pro
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to automate web tasks such as browsing, clicking, typing, and taking screenshots via the Model Context Protocol.
    1
    MIT

Appeared in Searches