Which integrations are available for this server?

Supported as a compatible web browser for WebDriver interaction, allowing the MCP server to automate Firefox browser sessions. Allows AI agents to control web browser sessions through Selenium WebDriver, enabling web scraping, automated testing, and form filling by providing tools for navigation, element finding, clicking, sending keystrokes, and retrieving page content.

How do I use Selenium MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Selenium MCP Server navigate to https://github.com and find the search input field" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

Selenium MCP Server

by themindmod

Overview Schema Related Servers Score Discussions

TypeScript

Local

Selenium MCP Server

smithery badge

An MCP server that uses Selenium to interact with a WebDriver instance. Built using the MCP-Server-Starter template.

Overview

This server allows AI agents to control a web browser session via Selenium WebDriver, enabling tasks like web scraping, automated testing, and form filling through the Model Context Protocol.

Related MCP server: mcp-selenium-python

Core Components

MCP Server: Exposes Selenium WebDriver actions as MCP tools.
Selenium WebDriver: Interacts with the browser.
MCP Clients: AI hosts (like Cursor, Claude Desktop) that can utilize the exposed tools.

Prerequisites

Node.js (v18 or later)
npm (v7 or later)
A WebDriver executable (e.g., ChromeDriver, GeckoDriver) installed and available in your system's PATH.
A compatible web browser (e.g., Chrome, Firefox).

Getting Started

Clone the repository:

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

Install dependencies:
```
npm install
```
Configure WebDriver:
- Ensure your WebDriver (e.g., chromedriver) is installed and in your PATH.
- Modify src/seleniumService.ts (you'll create this file) if needed to specify browser options or WebDriver paths.
Build the server:
```
npm run build
```
Run the server:
```
npm start
```
Alternatively, integrate it with an MCP host like Cursor or Claude Desktop (see Integration sections below).

Tools

This server will provide tools such as:

selenium_navigate: Navigates the browser to a specific URL.
selenium_findElement: Finds an element on the page using a CSS selector.
selenium_click: Clicks an element.
selenium_sendKeys: Sends keystrokes to an element.
selenium_getPageSource: Retrieves the current page source HTML.
(Add more tools as needed)

TypeScript Implementation

The server uses the @modelcontextprotocol/sdk and selenium-webdriver libraries.

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();

Development

Build: npm run build
Run: npm start (executes node build/index.js)
Lint: npm run lint
Format: npm run format

Debugging

Use the MCP Inspector or standard Node.js debugging techniques.

Integration with MCP Hosts

(Keep relevant sections from the original README for Cursor, Claude Desktop, Smithery, etc., updating paths and commands as necessary)

Cursor Integration

Build your server: npm run build
In Cursor: Settings > Features > MCP: Add a new MCP server.
Register your server:
- Select stdio as the transport type.
- Name: Selenium Server (or similar).
- Command: node /path/to/selenium-mcp-server/build/index.js.
Save.

Claude Desktop Integration

Build your server: npm run build

Modify claude_desktop_config.json:

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

Restart Claude Desktop.

Best Practices

Use TypeScript and Zod for type safety and validation.
Keep tools modular (e.g., one file per tool in src/tools/).
Handle WebDriver errors gracefully (e.g., element not found, navigation issues).
Ensure proper WebDriver shutdown (e.g., driver.quit() on server exit).
Follow MCP best practices for schemas, error handling, and content types.

Learn More

Credits

Based on the template created by Seth Rose:

Website: https://www.sethrose.dev
𝕏 (Twitter): https://x.com/TheSethRose
🦋 (Bluesky): https://bsky.app/profile/sethrose.dev

Available Tools

6 tools

browser_clickC

Perform click on a web page

ParametersJSON Schema

Name	Required	Description	Default
`element`	Yes	Human-readable element description
`ref`	Yes	Exact 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

Name	Required	Description	Default
`url`	Yes	The 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

Name	Required	Description	Default
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

Name	Required	Description	Default
`filename`	No	File name to save the screenshot to
`raw`	No	Whether 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

Name	Required	Description
`element`	Yes	Human-readable element description
`ref`	Yes	Exact target element reference from the page snapshot
`submit`	No	Whether to submit entered text (press Enter after)
`text`	Yes	Text 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

Name	Required	Description
`text`	No	The text to wait for
`textGone`	No	The text to wait for to disappear
`time`	No	The 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. Dates show when Glama detected each change.

6 tool updatesv1.0.0Aug 18, 2025
- First observedbrowser_click
- First observedbrowser_navigate
- First observedbrowser_snapshot
- First observedbrowser_take_screenshot
- First observedbrowser_type
- First observedbrowser_wait_for

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

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

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agent-web-actions
com.trycloudflare.clients-involving-billion-headers
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Web Scraping
2
agent-web-actions
com.trycloudflare.plates-spread-materials-optimum
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Agent Orchestration
2
browserbasehq-mcp-browserbaseOAuth
ai.smithery
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Browser Automation Web Scraping Agent Orchestration
23,406
playwright-mcp-server A
com.thenextgennexus
Headless browser primitives for AI agents when sites need real JS rendering.
Browser Automation Web Scraping
175

Related MCP Servers

Selenium MCP Server
Browser Automation Web Scraping App Automation
pshivapr
A
license
B
quality
C
maintenance
Enables AI assistants to automate web browser interactions through Selenium WebDriver. Supports multi-browser automation, element interaction, navigation, and web testing capabilities.
Updated a year ago (2025-10-12 14:09 UTC)
56
102
6
MIT
mcp-selenium-python
Browser Automation Web Scraping
pranavkakde
A
license
Not graded
quality
D
maintenance
Enables LLMs to automate browser tasks (navigation, clicks, text input) via Selenium through the Model Context Protocol.
Updated a year ago (2025-08-29 10:46 UTC)
1
GPL 3.0
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.
Updated 10 months ago (2025-11-13 00:16 UTC)
1
MIT
selenium-mcp
Browser Automation Web Scraping Testing & QA Tools
gaforov
A
license
B
quality
A
maintenance
Enables browser automation through the Model Context Protocol, allowing AI agents to control Chrome, Firefox, or Edge for tasks like navigation, clicking, typing, and screenshots.
Updated 2 months ago (2026-07-13 20:33 UTC)
39
86
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/themindmod/selenium-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server