Skip to main content
Glama
enesjakozh
themindmod

Selenium MCP Server

by themindmod
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Selenium MCP サーバー

鍛冶屋のバッジ

Seleniumを使用してWebDriverインスタンスとやり取りするMCPサーバー。MCP -Server-Starterテンプレートを使用して構築されています。

概要

このサーバーにより、AI エージェントは Selenium WebDriver を介して Web ブラウザー セッションを制御できるようになり、モデル コンテキスト プロトコルを介した Web スクレイピング、自動テスト、フォーム入力などのタスクが可能になります。

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 にインストールされ、使用可能になっていること。

  • 互換性のある Web ブラウザ(例: Chrome、Firefox)。

はじめる

  1. リポジトリをクローンします。

    git clone <your-repo-url> selenium-mcp-server
cd selenium-mcp-server

  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 インスペクターまたは標準の Node.js デバッグ手法を使用します。

MCPホストとの統合

(Cursor、Claude Desktop、Smisery などの元の README から関連セクションを保持し、必要に応じてパスとコマンドを更新します)

カーソル統合

  1. サーバーを構築する: npm run build

  2. カーソル内: Settings > Features > MCP : 新しい MCP サーバーを追加します。

  3. サーバーを登録する:

    • トランスポート タイプとしてstdioを選択します。

    • 名前: Selenium Server (または類似の名前)。

    • コマンド: node /path/to/selenium-mcp-server/build/index.js 。

  4. 保存。

クロードデスクトップ統合

  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/内のツールごとに 1 つのファイル)。

  • 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
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.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