Provides browser automation capabilities for Firefox, enabling navigation, element interaction, form filling, screenshots, and JavaScript execution.
Enhances GitHub Copilot Chat with browser automation capabilities, allowing it to navigate websites, interact with elements, capture screenshots, and execute JavaScript in the browser context.
Enables execution of custom JavaScript in browser contexts, allowing for advanced manipulation and extraction of data from web pages.
Integrates with Ollama to provide AI-powered screenshot analysis using Gemma3 models, allowing for visual interpretation of web pages, structure analysis, and element identification.
Built with TypeScript for type-safety throughout the codebase, providing robust typing for browser automation tools and functions.
Uses Zod for runtime validation of inputs and outputs, ensuring type safety and proper data validation during browser automation tasks.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Browser Server take a screenshot of the current page and save it as dashboard.png"
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.
A Model Context Protocol (MCP) server that provides browser automation capabilities using Playwright. This server enables AI assistants to interact with web pages through a standardized interface.
Perfect for web automation, testing, and debugging workflows with AI assistants including:
Chat.fans agents - Empower AI agents with web interaction capabilities in VS Code
GitHub Copilot Chat - Enhance your development workflow with browser automation
Any MCP-compatible AI assistant - Universal browser automation for AI tools
Multi-browser support: Chromium, Firefox, and WebKit
Comprehensive automation: Navigate, click, type, screenshot, and more
JavaScript execution: Run custom scripts in the browser context
Element interaction: Wait for elements, get text content, and interact with forms
Screenshot capabilities: Capture full pages or viewport screenshots
Type-safe: Built with TypeScript and runtime validation using Zod
Related MCP server: Playwright MCP Server
npm install
npm run buildMake sure Playwright browsers are installed:
npx playwright installFor system dependencies (Linux):
sudo npx playwright install-depsConfigure the MCP server in VS Code by adding to your settings.json or workspace configuration:
"mcp": {
"servers": {
"browser-automation": {
"command": "node",
"args": [
"/home/yourUserName/mcp-browser-server/build/index.js"
],
"env": {}
}
}
}Once configured, Chat.fans agents and GitHub Copilot Chat can use browser automation tools for web testing, scraping, and automation tasks.
Build: Ctrl+Shift+P → "Tasks: Run Task" → "build"
Development Mode: Ctrl+Shift+P → "Tasks: Run Task" → "dev"
Test MCP Server: Ctrl+Shift+P → "Tasks: Run Task" → "test-mcp-server"
launch_browser - Start a new browser instance
navigate - Go to a specific URL
click_element - Click on page elements
type_text - Enter text into form fields
screenshot - Capture page screenshots
get_element_text - Extract text from elements
wait_for_element - Wait for elements to appear/disappear
evaluate_javascript - Run custom JavaScript
get_console_logs - Get browser console logs (log, info, warn, error, debug)
analyze_screenshot - AI-powered screenshot analysis using Gemma3 (requires Ollama)
get_page_info - Get current page information
close_browser - Close the browser instance
scroll - Scroll the page in the specified direction (up/down/left/right)
check_scrollability - Check if the page is scrollable in specific directions
// Launch browser in headed mode for visual debugging
await launch_browser({ browser: "chromium", headless: false });
// Navigate to login page
await navigate({ url: "http://localhost:3000/login" });
// Fill in credentials
await type_text({ selector: "input[type='email']", text: "user@example.com" });
await type_text({ selector: "input[type='password']", text: "password123" });
// Submit form
await click_element({ selector: "button[type='submit']" });
// Wait for successful login
await wait_for_element({ selector: ".dashboard", timeout: 10000 });
// Check for any console errors during login
await get_console_logs({ level: "error" });
// Take screenshot of dashboard
await screenshot({ fullPage: true, path: "dashboard.png" });
// Get all console logs for debugging
await get_console_logs();
// Scroll down to see more content
await scroll({ direction: "down", pixels: 500, behavior: "smooth" });
// Check if page can be scrolled vertically
await check_scrollability({ direction: "vertical" });
// Scroll back to top
await scroll({ direction: "up", pixels: 500 });The MCP Browser Server includes comprehensive scrolling tools for navigating long pages and checking scroll capabilities:
The scroll tool allows you to scroll the page in any direction with fine-grained control:
// Scroll down by default amount (100px)
await scroll();
// Scroll in specific directions with custom distances
await scroll({ direction: "down", pixels: 300, behavior: "smooth" });
await scroll({ direction: "up", pixels: 200, behavior: "auto" });
await scroll({ direction: "left", pixels: 150 });
await scroll({ direction: "right", pixels: 150 });
// Smooth scrolling for better user experience
await scroll({ direction: "down", pixels: 500, behavior: "smooth" });Parameters:
direction: "up", "down", "left", "right" (default: "down")
pixels: Number of pixels to scroll (default: 100)
behavior: "auto" or "smooth" (default: "auto")
The check_scrollability tool determines whether a page can be scrolled in specific directions:
// Check both vertical and horizontal scrollability
await check_scrollability({ direction: "both" });
// Check only vertical scrolling
await check_scrollability({ direction: "vertical" });
// Check only horizontal scrolling
await check_scrollability({ direction: "horizontal" });Response includes:
Current scroll position
Maximum scroll distance
Whether scrolling is possible in each direction
Detailed position information
The analyze_screenshot tool provides AI-powered analysis of web pages using local Gemma3 models via Ollama. This feature can describe what's visible on a page, analyze page structure, and look for specific elements based on context.
Install Ollama: Download from ollama.ai
Install Gemma3 model:
ollama pull gemma3:4bStart Ollama service:
ollama serve// Take and analyze a screenshot with AI
await analyze_screenshot({
fullPage: true,
model: "gemma3:4b"
});// Get detailed analysis of page structure
await analyze_screenshot({
detailed: true,
pretext: "Focus on navigation elements and form fields"
});// Look for specific elements or issues
await analyze_screenshot({
pretext: "Check if there are any error messages or broken layouts",
path: "error-check.png"
});fullPage (boolean): Capture entire scrollable page vs viewport only
path (string): Optional file path to save the screenshot
pretext (string): Additional context or specific instructions for the AI
model (string): AI model to use (default: "gemma3:4b")
detailed (boolean): Request detailed structural analysis
gemma3:4b (default, good balance of speed and quality)
Any other vision-capable model available in your Ollama installation
# One-command setup (installs dependencies, browsers, and builds)
npm run setup
# Or step by step:
npm install
npx playwright install
npm run build# Build the project
npm run build
# Run in development mode
npm run dev
# Start the server
npm run start
# Development helper (shows all available commands)
npm run dev-helper helpThe project includes comprehensive tests in the tests/ directory:
# Run basic communication test
npm run test
# Run browser automation demo
npm run test:demo
# Run AI analysis test (requires Ollama)
npm run test:ai-simple
# Check system status
npm run test:status
# Run all tests
npm run test:allUse the development helper for common tasks:
# Show all available commands
npm run dev-helper help
# Quick setup from scratch
npm run dev-helper setup
# Run comprehensive tests
npm run dev-helper test
# Clean generated files
npm run dev-helper cleanFor more details about testing, see tests/README.md.
mcp-browser-server/
├── src/ # TypeScript source code
│ └── index.ts # Main MCP server implementation
├── build/ # Compiled JavaScript output
├── tests/ # Test scripts and documentation
│ ├── README.md # Testing documentation
│ ├── simple-test.mjs # Basic communication test
│ ├── demo-test.mjs # Browser automation demo
│ └── *.mjs # Additional test files
├── screenshots/ # Generated screenshots from tests
├── package.json # Project configuration
└── README.md # This fileDual License:
Personal Use: Free for personal, educational, and non-commercial use
Commercial Use: Requires a separate commercial license
See LICENSE for full terms. For commercial licensing inquiries, please contact us.
Take a screenshot and analyze it with AI (Gemma3) to describe what is visible on the page
| Name | Required | Description | Default |
|---|---|---|---|
| fullPage | No | Capture full scrollable page | |
| path | No | Path to save screenshot (optional) | |
| pretext | No | Optional context or specific instructions for what to look for in the analysis | |
| model | No | AI model to use for analysis (default: gemma3:4b) | gemma3:4b |
| detailed | No | Provide detailed structural analysis of the page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions the AI model (Gemma3) and result 'describe what is visible', but it does not disclose the compound nature (screenshot + AI call), potential latency, or prerequisites (e.g., browser must be open). The description is incomplete for a multi-step operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and purpose. It contains no fluff and efficiently conveys the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, composite operation), the description is minimal. It does not explain the return format or how the analysis relates to parameters like 'fullPage' or 'detailed'. Siblings like 'screenshot' exist, which helps context, but more detail on behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds mention of 'Gemma3' which is already in the model parameter default. It does not provide meaningful additional context beyond the parameter descriptions (e.g., what 'pretext' or 'detailed' do in practice).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Take a screenshot and analyze it with AI (Gemma3) to describe what is visible on the page'. It specifies the verb (take/analyze), resource (screenshot/page), and the AI analysis. This distinguishes it from sibling 'screenshot' which likely only captures without analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need AI-driven description of page content, but it does not explicitly state when to prefer this over alternatives like 'get_page_info' or 'evaluate_javascript'. No exclusions or 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.
Check if the page is scrollable in the specified direction
| Name | Required | Description | Default |
|---|---|---|---|
| direction | No | Direction to check for scrollability | both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose return value, side effects (e.g., whether it modifies state), or permissions needed. For a check tool, read-only assumption exists but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no fluff. Could be improved with return type info, but as is, it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., boolean). It does not, leaving the agent unsure of the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The tool description repeats 'in the specified direction' which aligns with the enum, but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks scrollability in a direction, differentiating it from sibling 'scroll' which performs scrolling. However, it does not explicitly state it returns a boolean.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'scroll'. The description lacks context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click on an element by CSS selector
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element to click | |
| timeout | No | Timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks detail on behavior like scrolling into view, handling of multiple matches, or error handling. Only states 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous text. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not explain return values or edge cases (e.g., element not found, timeout behavior). Incomplete for a DOM interaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and descriptions in schema are sufficient. Description adds no extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (Click), resource (element), and method (by CSS selector). Distinguishes from siblings like type_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage is implied from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the current browser instance
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the basic action of closing. No annotations exist to compensate. Important aspects like irreversible loss of session data or browser state are not disclosed, leaving the agent to infer the implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no unnecessary words. Every sentence—just one—earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and the sibling suite context, the description is nearly adequate. However, it omits any mention of side effects or safety considerations, which an agent might need for robust execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and fully covered (100%), so the baseline is 3. The description adds no parameter information beyond the schema, which is acceptable given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the current browser instance' uses a specific verb ('Close') and clearly identifies the resource ('current browser instance'). It effectively distinguishes the tool from its sibling 'launch_browser', which performs the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. While the purpose is clear, there is no mention of preconditions (e.g., ensuring a browser is open) or related operations (e.g., launching before closing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the browser context
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Execute JavaScript in the browser context,' omitting details about what the execution environment supports (e.g., DOM access, async, returns), potential side effects, or error handling. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly conveys the tool's purpose. It is front-loaded and contains no unnecessary words, but it could benefit from additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing arbitrary JavaScript in a browser, the description is too minimal. It lacks information about return values, permissions, and side effects, making it incomplete for an agent to use safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'script' has a schema description ('JavaScript code to execute'). The tool description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute'), the resource ('JavaScript'), and the context ('in the browser context'). This distinguishes it from sibling tools like click_element and navigate, which 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.
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, nor are there any exclusions or prerequisites mentioned. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get console logs from the browser
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Filter logs by level | |
| clear | No | Clear console logs after retrieving |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the schema. For example, it does not mention that the tool can clear logs after retrieval (as indicated by the 'clear' parameter).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but still conveys the basic purpose. It could be improved by including more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks important context such as the scope (current page/tab), format of logs, and details about optional filtering. Given the simplicity of the tool, it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves console logs, which matches the tool name. However, it does not differentiate from sibling tools, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get text content of an element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element | |
| timeout | No | Timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks details on behavior such as what happens if the element is not found, whether it waits, or the return format. With no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but could slightly expand on behavior without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description omits any mention of return value or error handling, which is needed given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the text content of an element, distinguishing it from sibling tools like click_element or type_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It only states the purpose without disclosing behavioral traits such as whether the tool is read-only, its side effects, or the nature of the returned information. This is insufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the core purpose, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, yet the description does not specify what information is returned (e.g., URL, title, HTML). This leaves the agent without sufficient context to understand the tool's output, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100% (empty schema). The description adds no parameter information, but with zero parameters, the baseline is 4, which is appropriate as the schema fully defines the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves information about the current page, distinguishing it from other tools that perform actions or extract specific elements. However, it lacks specificity on what exact information is returned (e.g., URL, title, HTML), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_element_text or evaluate_javascript. The description does not include any when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch a new browser instance (chromium, firefox, or webkit)
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser engine to use | chromium |
| headless | No | Run browser in headless mode | |
| viewport | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action without disclosing side effects (e.g., browser becomes active context, resource consumption, need to close). Behavioral traits needed for safe invocation are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core action and supported browsers. No wasted words; front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is too minimal. It fails to explain when to use the tool, what happens after launch, or how to manage the browser instance (e.g., lifecycle, interaction prerequisites).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (browser and headless described, viewport not). The description adds no extra parameter meaning beyond listing browsers; it does not clarify default behavior or viewport structure. Adequate but does not compensate for the missing viewport description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Launch), the object (a new browser instance), and lists the supported browsers (chromium, firefox, webkit). It distinguishes from siblings like close_browser and navigate, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 does not mention prerequisites (e.g., that a browser should be closed before launching another) or contrast with close_browser or navigate. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page
| Name | Required | Description | Default |
|---|---|---|---|
| fullPage | No | Capture full scrollable page | |
| path | No | Path to save screenshot (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action without mentioning side effects, output format, or that it is a read-only operation. Important traits like whether fullPage screenshots scroll the page are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and without unnecessary words. It earns its place by conveying the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 optional parameters and no output schema, the description is minimal. It does not explain return values, the effect of fullPage, or path behavior (e.g., where saved if omitted). More details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with both parameters described (fullPage and path). The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('of the current page'). It is a specific verb+resource pairing that distinguishes from sibling tools like analyze_screenshot or check_scrollability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., analyze_screenshot for analyzing an existing screenshot, or check_scrollability to decide fullPage usage). The description lacks context on prerequisites or typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll the page in the specified direction
| Name | Required | Description | Default |
|---|---|---|---|
| direction | No | Direction to scroll | down |
| pixels | No | Number of pixels to scroll (optional) | |
| behavior | No | Scrolling behavior | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether scrolling triggers events, which element is scrolled, or behavior of the 'auto' vs 'smooth' modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with key information, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 optional params and no output schema, the description is adequate but lacks context about which element is scrolled and the effect of the 'behavior' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no value beyond what the schema already provides for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scroll the page in the specified direction' clearly states the verb and resource. It distinguishes the tool from siblings like 'check_scrollability' and 'navigate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into an input field
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the input element | |
| text | Yes | Text to type | |
| delay | No | Delay between keystrokes in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral context. It does not disclose that it types with a configurable delay (though schema covers this) or that it may fail on non-input elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Appropriate for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters and no output schema, the description is adequate but omits details like clearing the field, error handling, or behavior on non-input elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The tool description adds no additional meaning beyond the schema, but baseline is 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('type text') and target ('input field'). It distinguishes from siblings like click_element and get_element_text, but lacks specificity about the typing behavior (e.g., character-by-character, delay).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like click_element or evaluate_javascript. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for an element to appear or disappear
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element | |
| timeout | No | Timeout in milliseconds | |
| state | No | State to wait for | visible |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose key behavioral traits like timeout behavior (error vs. silent failure), whether it blocks, or if it returns a value. The agent is left to infer these from the schema's 'timeout' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is too brief to convey important context. It is appropriately sized but lacks substance beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It does not explain what the tool returns (e.g., boolean, void), error behavior, or side effects, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description adds no additional meaning beyond what the schema already provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Wait for an element to appear or disappear', which is a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like 'click_element' or 'type_text', though those have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool compared to alternatives, such as checking if an element exists or waiting for page load. The description lacks any context about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyze_screenshotcheck_scrollabilityclick_elementclose_browserevaluate_javascriptget_console_logsget_element_textget_page_infolaunch_browsernavigatescreenshotscrolltype_textwait_for_elementEach tool has a clear, distinct purpose. Even similar tools like screenshot and analyze_screenshot are differentiated by the addition of AI analysis. No two tools overlap in functionality.
Most tools follow a verb_noun pattern (e.g., click_element, get_page_info). A few outliers like screenshot (noun used as verb) and navigate (verb only) introduce minor inconsistency, but the overall pattern is clear and predictable.
With 14 tools, the set covers the core browser automation tasks without being bloated. Each tool serves a specific purpose, and the count feels well-scoped for the domain.
The tool set covers essential browser operations: navigation, clicking, typing, scrolling, screenshots, JavaScript execution, and console logs. Minor gaps like form submission or cookie management are present but do not severely impact core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Wladastic/AutoProbeMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
