The Enhanced Web Scraper MCP Server provides comprehensive web scraping, testing, and analysis capabilities across traditional websites, React applications, and React Native web projects.
• Universal Web Scraping: Extract content from any website using CSS selectors with React Native testID/aria-label fallbacks, supporting multiple browsers (Chromium, Firefox, WebKit) and mobile viewport emulation • React Application Testing: Perform multi-step interactions (clicks, fills, taps, swipes, scrolls) on React and React Native web apps with optional hydration waiting and mobile gesture simulation • Deep Component Analysis: Inspect React component trees, props, and state; execute custom JavaScript in React context; wait for specific conditions like navigation or data loading • Enhanced Content Extraction: Retrieve readable content in markdown/text format, comprehensive page information (title, meta tags, performance metrics), and DOM element attributes with computed styles • Development Tools: Monitor Expo/Metro server status, test dropdown interactions with error capture, screenshots, and robust error handling with configurable timeouts • Backward Compatibility: Maintains full support for traditional websites and standard React applications while adding React Native web capabilities
Enables web scraping and automated testing of Create React App applications with support for React hydration detection and component interaction
Provides comprehensive CSS selector support for web scraping with automatic fallback strategies for element targeting across different web frameworks
Offers specialized tools for testing and inspecting Expo web projects, including Metro bundler health checks and React Native web component analysis
Supports web scraping and testing through Firefox browser automation using Playwright
Enables JavaScript execution within React contexts for advanced web application inspection and manipulation
Provides development server monitoring and health checks for Metro bundler in React Native web applications
Supports web scraping and automated testing of Next.js applications with React-specific features like hydration waiting and component inspection
Offers comprehensive React application testing and inspection capabilities, including component tree analysis, state management, and React Native web support with mobile viewport emulation
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., "@Enhanced Web Scraper MCP Server take a screenshot of the homepage and check for empty states"
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 professional Model Context Protocol (MCP) server for web scraping, React app testing, and React Native web app inspection using Playwright. Fully backward compatible with regular websites and standard React applications.
🔥 Context-Optimized Screenshots - Screenshots return only file paths and analysis text (no base64 data)
📊 Enhanced Page Analysis - Detailed element counting, content structure analysis, and page state inspection
🔍 Comprehensive Comparison Tools - Visual similarity analysis with layout, color, and typography detection
💾 File-Based Output - All screenshots saved to /tmp/ with structured analysis data
🎯 Smart Content Detection - Automatically detects empty states, loading indicators, and content availability
Enhanced Error Handling - Comprehensive input validation and error reporting
Optimized Performance - Reduced code duplication and improved efficiency
Standardized Timeouts - Configurable timeout constants for reliability
Professional Code Structure - ES6+ best practices and maintainable architecture
Related MCP server: Web Inspector MCP
This enhanced server maintains 100% compatibility with:
✅ Regular websites (HTML, CSS, JavaScript)
✅ Standard React applications (Create React App, Next.js, etc.)
✅ Traditional web scraping workflows
✅ Existing CSS selectors and interactions
Plus new enhanced support for:
🆕 React Native web applications
🆕 Expo web projects
🆕 Mobile viewport emulation
🆕 Advanced React component inspection
Tool | Purpose | Best For |
Context-free screenshot capture | Visual analysis, UI documentation | |
Visual UI comparison with semantic analysis | UI replication, visual regression testing | |
Universal web scraping | Content extraction, data collection | |
React app testing with mobile gestures | UI testing, interaction automation | |
Page analysis with React insights | Performance monitoring, framework detection | |
Clean content extraction | Documentation, article processing | |
Smart element waiting | Dynamic content, loading states | |
React component analysis | Component debugging, state inspection | |
React state management | Hydration, navigation, data loading | |
JavaScript execution in React context | Advanced debugging, custom scripts | |
Expo development server status | Development workflow, debugging | |
DuckDuckGo search with result extraction | Research, finding relevant URLs for content extraction |
No Base64 Data: Screenshots return only file paths and analysis text
Minimal Context Usage: Dramatically reduced token consumption per screenshot
File-Based Storage: All images saved to /tmp/ for external access
Structured Analysis: Rich text analysis without heavy image data
Empty State Detection: Automatically identifies when pages have no meaningful content
Table Population Verification: Counts table rows to verify data is actually displaying
Loading State Recognition: Detects and waits for loading indicators to disappear
Content Structure Analysis: Provides detailed breakdown of page elements
Every visual tool provides:
📊 Analysis Text: Element counts, text content, structural analysis
📁 File Path: Saved screenshot location for external viewing
🎯 Pass/Fail Status: Built-in success criteria for automated workflows
Perfect for:
UI Migration Verification: Compare source vs target implementations
Mock Data Validation: Verify that mock data is actually displaying
Visual Regression Testing: Ensure UI changes don't break layouts
Component Testing: Validate React components render correctly
Configurable Similarity Thresholds: Built-in pass/fail criteria for visual comparisons
Populated Data Requirements: Detects empty states that prevent meaningful comparison
Comprehensive Reporting: Detailed analysis for debugging visual differences
take_screenshot - Context-Free Screenshot CaptureCaptures screenshots with comprehensive analysis while keeping context usage minimal.
{
url: "https://example.com",
browser: "chromium",
device: "iPhone 12", // Optional device emulation
fullPage: true,
waitForSPA: true // Auto-detects and waits for React/Vue/Angular apps
}Returns:
📊 Comprehensive Analysis: Element counts, page structure, content preview
📁 File Path: Screenshot saved to /tmp/screenshot-[timestamp].png
🎯 Content Status: Pass/fail indicators for populated data
Example Output:
📸 Screenshot saved to: /tmp/screenshot-1234567890.png
📄 Page Analysis:
- Title: "My React App"
- Has Content: ✅
- Visible Elements: 247
📊 Content Elements:
- Headings: 3
- Paragraphs: 12
- Buttons: 8
- Tables: 1
- Table Rows: 15 ← Indicates populated data!
📝 Page Content Preview:
Welcome to our service platform. Here you can find contractors...compare_screenshots - Context-Free Visual ComparisonCompares two pages with comprehensive analysis while maintaining minimal context usage.
{
urlA: "https://source-design.com", // Source/reference
urlB: "https://your-implementation.com", // Target/implementation
browser: "chromium",
threshold: 0.1, // Similarity threshold (0-1)
analyzeLayout: true, // Detect alignment differences
analyzeColors: true, // Exact color comparison
analyzeTypography: true, // Font size/weight analysis
waitForSPA: true // Smart SPA detection
}Returns:
📊 Visual Similarity Score: Percentage match with pass/fail status
🏗️ Structural Comparison: Element counts, table rows, content structure
🎨 Layout Analysis: Alignment differences, positioning issues
📁 File Paths: Both screenshots saved to /tmp/ for external viewing
Example Output:
📸 Screenshots saved:
- Source: /tmp/compare-source-1234567890.png
- Target: /tmp/compare-target-1234567891.png
📊 VISUAL SIMILARITY: 87.3% ✅ PASS
🏗️ Structural Comparison:
- Tables: 1 → 1
- Table Rows: 0 → 8 ← Target has populated data!
- Buttons: 12 → 12
📋 Layout Analysis:
- 2 regions with significant layout differences
- Content appears centered in source but left-aligned in target
🎨 Color Analysis:
- Minor color differences detected
- Example: rgb(229, 122, 68) → rgb(225, 118, 64)scrape_page - Universal Web ScrapingWorks with any website - regular HTML, React apps, or React Native web.
Regular website example:
{
url: "https://example.com",
selector: ".article-title", // Standard CSS selector
screenshot: true
}React Native web example:
{
url: "http://localhost:8081",
selector: "login-button", // Will try testID, aria-label fallbacks
mobileViewport: true,
device: "iPhone 12"
}test_react_app - Universal React TestingWorks with any React application - standard React or React Native web.
Standard React app example:
{
url: "http://localhost:3000",
waitForHydration: false, // Optional for regular React apps
actions: [
{ type: "click", selector: "#submit-button" },
{ type: "fill", selector: "input[name='email']", value: "test@example.com" }
]
}React Native web example:
{
url: "http://localhost:8081",
device: "iPhone 12",
waitForHydration: true, // Recommended for RN web
actions: [
{ type: "tap", selector: "login-button" },
{ type: "swipe", selector: "scroll-view", value: "up" }
]
}get_page_info - Enhanced Page AnalysisProvides comprehensive information for any web page with React-specific insights.
{
url: "https://any-website.com", // Works with any URL
includePerformance: true
}extract_content - Clean Content ExtractionExtract clean, readable content from web pages without HTML/CSS clutter. Perfect for documentation, articles, and structured content consumption.
{
url: "https://docs.example.com/api-guide",
includeLinks: true, // Extract and categorize hyperlinks
format: "markdown" // Output format: 'markdown' or 'text'
}Output Example:
# API Documentation
## Authentication
You need to obtain an API key [1] from the developer portal [2].
### Rate Limits
See the rate limiting guide [3] for details.
---
## Links Found:
[1] https://example.com/api-keys (internal)
[2] https://developer.example.com (external)
[3] https://example.com/docs/rate-limits (internal)Features:
Clean Structure - Preserves headings, paragraphs, lists, code blocks
Link Extraction - Categorizes links as internal, external, anchor, or download
Content Filtering - Removes navigation, ads, sidebars automatically
Multiple Formats - Markdown or plain text output
wait_for_element - Smart Element WaitingIntelligent element waiting with automatic selector strategy fallbacks.
{
url: "https://example.com",
selector: ".loading-spinner", // CSS selector with RN fallbacks
timeout: 10000
}inspect_react_app - React Component AnalysisDeep inspection of React applications (works best with React Native web).
wait_for_react_state - React State ManagementWait for React-specific conditions like hydration, navigation, data loading.
execute_in_react_context - JavaScript ExecutionExecute JavaScript in React context for advanced inspection.
check_expo_dev_server - Expo Development ToolsCheck Expo/Metro bundler status for development workflows.
The server uses intelligent selector strategies:
Primary: Direct CSS selector (e.g., #button, .class, input[name='email'])
Fallback 1: TestID attribute ([data-testid="button"])
Fallback 2: Accessibility label ([aria-label="Button"])
Fallback 3: AccessibilityLabel ([accessibilityLabel="Button"])
This ensures regular CSS selectors work normally while providing React Native web compatibility.
// Verify data is actually displaying without burning context
{
url: "http://localhost:3000/data-table",
fullPage: true,
waitForSPA: true
}
// Returns: File path + "Table Rows: 8" ← Confirms data is populated!// Compare source vs target implementation efficiently
{
urlA: "http://localhost:3001/page", // Source
urlB: "http://localhost:3000/page", // Target
threshold: 0.05, // High similarity requirement
analyzeLayout: true,
analyzeColors: true
}
// Returns: File paths + "VISUAL SIMILARITY: 96.2% ✅ PASS"// Works exactly like before
{
url: "https://news.ycombinator.com",
selector: ".storylink",
screenshot: false
}// Standard React app (Create React App, Next.js, etc.)
{
url: "http://localhost:3000",
actions: [
{ type: "click", selector: "button.login" },
{ type: "fill", selector: "#username", value: "testuser" }
]
}// React Native web with enhanced features
{
url: "http://localhost:8081",
device: "iPhone 12",
waitForHydration: true,
actions: [
{ type: "tap", selector: "login-button" }, // Uses testID
{ type: "swipe", selector: "scroll-view", value: "up" }
]
}// Extract clean content from documentation
{
url: "https://docs.react.dev/learn",
includeLinks: true,
format: "markdown"
}npm install
npx playwright install# Take a context-free screenshot and analyze content
q chat "Take a screenshot of localhost:3000/data-page and analyze the content"
# Compare pages efficiently without context bloat
q chat "Compare the page between localhost:3001 and localhost:3000"
# Mock data verification with minimal context usage
q chat "Verify that the data table is populated at localhost:3000"
# Works with any website
q chat "Scrape the headlines from https://news.ycombinator.com"
# Works with React apps
q chat "Test the login flow on my React app at localhost:3000"
# Enhanced React Native web support
q chat "Inspect the React Native web app at localhost:8081"
# Extract clean content for reading
q chat "Extract the main content from https://docs.react.dev/learn"Before: 50-200KB base64 data per screenshot
After: Only text analysis (~1-2KB per screenshot)
Result: 50-100x reduction in context consumption
Screenshots saved to /tmp/ with timestamps
External tools can access images directly
No context pollution from image data
Structured analysis data remains in conversation
More screenshots possible per conversation
Focus on analysis rather than data transfer
Cleaner conversation history
Faster response times
Input Validation - Server validates required parameters and provides clear error messages
Timeout Configuration - Default timeouts are optimized but can be adjusted per request
Browser Cleanup - Automatic resource cleanup prevents memory leaks
Use standard CSS selectors (.class, #id, tag[attribute])
Set mobileViewport: false (default) for desktop sites
Set waitForHydration: false (default) for non-React sites
Set waitForHydration: true for better reliability
Use semantic selectors when possible
Check browser console for React errors
Use testID attributes in your components
Enable mobileViewport or specify device
Set waitForHydration: true
Use inspect_react_app to see available elements
MIT
duckduckgo_search - Web Search IntegrationSearch DuckDuckGo and extract result links with titles and snippets for further content extraction.
query (required): Search query string
maxResults (optional): Maximum results to return (1-10, default: 5)
# Search for React documentation
q chat "Search DuckDuckGo for 'React hooks documentation'"
# Get more results
q chat "Search DuckDuckGo for 'Node.js best practices' with maxResults=8"
# Combine with content extraction
q chat "Search for 'AWS Lambda tutorials' then extract content from the top 2 results"Research: Find relevant URLs for content extraction
Documentation Discovery: Locate official docs and tutorials
Content Pipeline: Search → Extract → Analyze workflow
Development Research: Find code examples and solutions
Perfect for combining with extract_content:
Use duckduckgo_search to find relevant URLs
Use extract_content on the top results
Get comprehensive information on any topic
No Bot Detection: More lenient than Google for automated requests
Free & Unlimited: No API keys or rate limits required
Privacy-Focused: Doesn't track users or requests
Reliable Results: High-quality search results for development topics
Note: This tool extracts public search results only (completely legal). DuckDuckGo is more automation-friendly than Google, providing reliable results without anti-bot measures.
Check if Expo development server is running and get app status
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Host where Expo dev server is running | localhost |
| port | No | Port where Expo dev server is running |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions checking server status but doesn't describe what 'running' means (e.g., HTTP response codes, timeout behavior), what 'app status' includes (e.g., bundle status, connected devices), error handling, or network requirements. This leaves significant gaps for a tool that interacts with external services.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('check if... running and get... status') directly contributes to understanding the tool's function, with zero redundant information.
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 for a tool that checks external service status. It doesn't explain what constitutes 'running' (success criteria), what 'app status' returns, error conditions, or network dependencies. For a tool with 2 parameters and potential complexity in interpreting server responses, this leaves the agent with insufficient context.
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 the schema already documents both parameters (host and port) with clear descriptions and defaults. The description adds no additional parameter semantics beyond what's in the schema, but doesn't need to compensate for gaps. This 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('check' and 'get') and identifies the target resource ('Expo development server' and 'app status'). It distinguishes itself from sibling tools by focusing on server status checking rather than UI interaction or testing. However, it doesn't explicitly differentiate from potential non-sibling alternatives like general network checking tools.
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 doesn't mention prerequisites (e.g., when Expo dev server should be running), exclusions (e.g., not for production servers), or compare with sibling tools that might overlap in functionality. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in React context to inspect components, state, or trigger actions
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser engine to use | chromium |
| script | Yes | JavaScript code to execute in the browser context | |
| url | Yes | URL of the React app | |
| waitForReact | No | Wait for React to be available before executing |
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 executing JavaScript in a browser context but does not cover critical aspects such as security implications, performance impact, error handling, or what happens if React is not available (beyond the 'waitForReact' parameter). For a tool that interacts with external systems and executes arbitrary code, this is a significant gap in transparency.
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, efficient sentence that front-loads the core action ('Execute JavaScript in React context') and follows with the purpose. There is no wasted verbiage, and every word contributes to understanding the tool's function, making it highly concise and well-structured.
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 JavaScript in a browser with React, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error responses), does not explain the return values or output format, and fails to address security or performance considerations. This makes it inadequate for safe and effective use by an 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description does not add any semantic details beyond what the schema provides (e.g., it does not explain the significance of 'React context' for the script or how the browser choice affects execution). Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 verb ('execute JavaScript') and the resource ('in React context'), and specifies the purpose ('to inspect components, state, or trigger actions'). It distinguishes from generic JavaScript execution tools by specifying the React context, but does not explicitly differentiate from sibling tools like 'inspect_react_app' or 'test_react_app', which may have overlapping functionality.
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 sibling tools, prerequisites, or specific scenarios where this tool is preferred over others like 'inspect_react_app' or 'test_react_app'. The lack of usage context leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive information about a web page (title, meta tags, performance metrics)
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser engine to use | chromium |
| includePerformance | No | Include performance metrics | |
| url | Yes | URL to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions what information is retrieved, it doesn't describe how the tool behaves—such as whether it loads the page in a browser, potential timeouts, error handling, or any side effects. This is a significant gap for a tool that likely involves network operations.
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, efficient sentence that front-loads the core purpose and lists key outputs without any wasted words. It's appropriately sized for the tool's complexity and provides essential information concisely.
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 lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like how the tool operates, potential errors, or output format details. For a tool that likely involves web scraping or analysis, more context on performance implications or limitations would be helpful.
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 the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the relationship between 'includePerformance' and the output or typical values for 'url'. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose with a specific verb ('Get') and resource ('web page'), and lists the types of information retrieved (title, meta tags, performance metrics). However, it doesn't explicitly differentiate this tool from sibling tools like 'scrape_page', which might have overlapping functionality.
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 like 'scrape_page' or other sibling tools. It lacks context about prerequisites, typical use cases, or any explicit when/when-not instructions, leaving the agent to infer usage based on 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.
Inspect a DOM element by selector and return its attributes, text, and computed styles
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | chromium | |
| properties | No | Optional list of CSS properties | |
| selector | Yes | CSS selector of element | |
| url | Yes | Page URL to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool inspects and returns data, but doesn't cover critical aspects like whether it navigates to the URL, handles errors (e.g., if selector not found), requires page loading, or has performance implications. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core action and output. Every word earns its place with no redundancy or fluff, making it easy to parse quickly.
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 for a tool with 4 parameters and behavioral complexity. It lacks details on error handling, return format (e.g., structure of attributes/text/styles), dependencies (e.g., page state), and how it interacts with sibling tools. This leaves the agent with insufficient context for reliable use.
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 75% (3 of 4 parameters have descriptions), so the baseline is 3. The description adds some value by implying the 'selector' and 'url' parameters are used for inspection, but doesn't elaborate on 'properties' (CSS properties) or 'browser' beyond what the schema provides. It compensates minimally for the 25% gap in schema 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 tool's purpose: 'Inspect a DOM element by selector and return its attributes, text, and computed styles.' It specifies the verb ('inspect'), resource ('DOM element'), and output details. However, it doesn't explicitly differentiate from siblings like 'get_page_info' or 'scrape_page', which might also involve element inspection.
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 doesn't mention prerequisites (e.g., needing a loaded page), exclusions, or comparisons to sibling tools like 'wait_for_element' or 'inspect_react_app'. Usage is implied by the action but not explicitly contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect React Native web app with component tree, props, and state analysis
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser engine to use | chromium |
| device | No | Device to emulate (e.g., "iPhone 12", "Pixel 5") | |
| includeComponentTree | No | Include React component tree analysis | |
| includeState | No | Include React state inspection (requires React DevTools) | |
| url | Yes | URL of the React Native web app | |
| waitForHydration | No | Wait for React hydration to complete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions analysis of 'component tree, props, and state', it doesn't describe what the tool actually does behaviorally: Does it launch a browser? Does it require React DevTools? Is it read-only or does it modify the app? What's the output format? The description is too vague about the tool's operational behavior.
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, efficient sentence that gets straight to the point: 'Inspect React Native web app with component tree, props, and state analysis.' There's no wasted verbiage, and it's appropriately sized for the tool's complexity. Every word 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 complexity (6 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what the tool actually produces as output, how it interacts with the app, or what behavioral constraints exist. For an inspection tool that presumably launches browsers and analyzes React applications, more context about the operation and results is needed.
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 the schema already documents all 6 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions 'component tree, props, and state analysis' which loosely maps to 'includeComponentTree' and 'includeState' parameters, but doesn't provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Inspect React Native web app with component tree, props, and state analysis.' It specifies the verb ('inspect'), resource ('React Native web app'), and scope of analysis. However, it doesn't explicitly differentiate from sibling tools like 'test_react_app' or 'inspect_element', which could have overlapping functionality.
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. With siblings like 'test_react_app', 'inspect_element', and 'check_expo_dev_server', there's no indication of when this inspection-focused tool is preferred over testing or other inspection tools. The description lacks any 'when-to-use' or 'when-not-to-use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape content from any web page (regular websites, React apps, or React Native web apps) using Playwright
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser engine to use | chromium |
| device | No | Device to emulate (e.g., "iPhone 12", "Pixel 5") - for mobile web apps | |
| mobileViewport | No | Use mobile viewport (primarily for React Native web apps) | |
| screenshot | No | Take a screenshot of the page | |
| selector | No | CSS selector to target specific elements (supports regular CSS and React Native testID/aria-label fallbacks) | |
| url | Yes | URL to scrape | |
| waitFor | No | Wait for specific selector or timeout in ms (e.g., "2000" or "#my-element") |
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 implementation (Playwright) and target page types, but lacks critical details: it doesn't specify what 'scrape content' entails (e.g., returns HTML, text, structured data), potential side effects (e.g., network requests, JavaScript execution), error handling, or performance implications like rate limits or timeouts.
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, efficient sentence with zero waste. It's front-loaded with the core purpose and includes relevant technical context (Playwright, page types) without unnecessary elaboration. Every word 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 complexity of a web scraping tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on return values (critical since there's no output schema), error cases, behavioral constraints, and differentiation from siblings. This leaves significant gaps for an AI agent to understand the tool fully.
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 the schema fully documents all 7 parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining interactions between parameters (e.g., how 'device' and 'mobileViewport' relate) or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('scrape') and resource ('content from any web page'), specifying the target scope (regular websites, React apps, React Native web apps) and implementation method (Playwright). However, it doesn't explicitly differentiate from sibling tools like 'get_page_info' or 'inspect_element', which might have overlapping 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 is provided on when to use this tool versus alternatives. The description mentions target page types but doesn't specify scenarios where this tool is preferred over siblings like 'get_page_info' or 'inspect_element', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test dropdown interactions with comprehensive console error capture and page state monitoring
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser engine to use | chromium |
| dropdownSelector | Yes | CSS selector, testID, or text content to identify the dropdown button | |
| takeScreenshots | No | Take before/after screenshots | |
| url | Yes | URL of the React app | |
| waitAfterClick | No | Time to wait after clicking to capture errors (ms) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'comprehensive console error capture and page state monitoring,' which hints at monitoring behavior, but lacks critical details: what specific errors are captured, how page state is monitored, whether this is a read-only or destructive operation, authentication requirements, or rate limits. For a testing tool with no annotation coverage, 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, efficient sentence that front-loads the core purpose: 'Test dropdown interactions with comprehensive console error capture and page state monitoring.' Every word earns its place, with no redundancy or unnecessary elaboration.
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 a testing tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, output format, and how it differs from sibling tools. The high schema coverage helps with parameters, but overall context for effective use is inadequate.
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 the schema fully documents all 5 parameters. The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter interactions, default behaviors, or usage examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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's purpose: 'Test dropdown interactions with comprehensive console error capture and page state monitoring.' It specifies the action (test dropdown interactions) and key features (error capture, state monitoring). However, it doesn't distinguish this from sibling tools like 'test_react_app' or 'inspect_react_app', which might have overlapping functionality.
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. With sibling tools like 'test_react_app', 'inspect_react_app', and 'check_expo_dev_server', there's no indication of when this specific dropdown testing tool is preferred or what scenarios it's designed for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test any React app (regular React or React Native web) with enhanced interactions and mobile gestures
| Name | Required | Description | Default |
|---|---|---|---|
| actions | Yes | Array of actions to perform on the React Native web app | |
| browser | No | Browser engine to use | chromium |
| device | No | Device to emulate (e.g., "iPhone 12", "Pixel 5") | |
| url | Yes | URL of the React app (e.g., http://localhost:3000 for regular React, http://localhost:8081 for RN web) | |
| waitForHydration | No | Wait for React hydration before starting tests (recommended for React apps, especially React Native web) |
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 'enhanced interactions and mobile gestures,' which adds some context beyond basic testing, but fails to cover critical aspects like whether this is a read-only or destructive operation, performance implications, error handling, or output format. For a complex testing tool with multiple parameters, 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, efficient sentence that front-loads the core purpose without unnecessary details. It uses parentheses for clarification and avoids redundancy, making it appropriately sized for its informational value.
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, no annotations), the description is incomplete. It lacks details on behavioral traits, output expectations, error conditions, and how it differs from siblings. Without annotations or output schema, the description should compensate more to guide effective use.
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 description adds no specific parameter semantics beyond what the input schema provides. Since schema description coverage is 100%, the baseline score is 3. The description does not elaborate on parameter usage, relationships, or examples, such as how 'actions' interact with 'device' emulation or 'waitForHydration' timing.
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's purpose: 'Test any React app (regular React or React Native web) with enhanced interactions and mobile gestures.' It specifies the verb ('test'), resource ('React app'), and scope ('regular React or React Native web'), though it doesn't explicitly differentiate from sibling tools like 'test_dropdown_with_error_capture' or 'inspect_react_app'.
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 minimal guidance on when to use this tool. It mentions 'enhanced interactions and mobile gestures,' which hints at its capabilities, but offers no explicit when-to-use or when-not-to-use advice compared to alternatives like 'scrape_page' or 'execute_in_react_context.' No prerequisites or exclusions are stated.
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 on the page (useful for dynamic React content)
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser engine to use | chromium |
| selector | Yes | CSS selector to wait for | |
| timeout | No | Maximum time to wait in milliseconds | |
| url | Yes | URL to monitor |
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 waiting for dynamic React content but doesn't describe what happens on success/failure, whether it polls continuously, what error conditions exist, or what permissions/browser state is required. The description is too minimal for a tool that interacts with browser automation.
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 with just one sentence containing 11 words. Every word earns its place: 'Wait for an element to appear on the page' states the core purpose, and '(useful for dynamic React content)' adds valuable context. No wasted words or redundancy.
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 browser automation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens when the element doesn't appear, or how it interacts with the browser context. The React mention is helpful but insufficient for the tool's complexity.
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 the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate since the schema does the heavy lifting, though the description doesn't compensate with additional context about parameter interactions.
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's purpose: 'Wait for an element to appear on the page' with the specific verb 'wait' and resource 'element'. It distinguishes from some siblings like 'scrape_page' or 'get_page_info' by focusing on waiting rather than retrieving information, though it doesn't explicitly differentiate from all siblings like 'wait_for_react_state'.
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 implied usage guidance with '(useful for dynamic React content)', suggesting it's for React-based pages. However, it doesn't explicitly state when to use this tool versus alternatives like 'wait_for_react_state' or 'inspect_element', nor does it provide clear exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for React component state changes, data loading, or navigation
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser engine to use | chromium |
| condition | Yes | Type of condition to wait for | |
| selector | No | CSS selector or testID to wait for (for custom condition) | |
| timeout | No | Maximum time to wait in milliseconds | |
| url | Yes | URL to monitor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions waiting for conditions but doesn't describe what happens on success/failure, error handling, or side effects. For a tool with 5 parameters and no annotations, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality, making it easy to understand at a glance while being appropriately sized for its complexity.
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 tool with 5 parameters, no annotations, and no output schema, the description is minimal but covers the basic purpose. It doesn't address behavioral aspects like return values or error conditions, which are important given the lack of structured data. It's adequate but has clear gaps in 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 the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining how conditions interact or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose as waiting for React component state changes, data loading, or navigation, which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'wait_for_element' or 'test_react_app', which might have overlapping functionality in a React testing context.
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. With sibling tools like 'wait_for_element' and 'test_react_app' present, there's no indication of scenarios where this tool is preferred or when other tools might be more appropriate, leaving usage context unclear.
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.0check_expo_dev_serverexecute_in_react_contextget_page_infoinspect_elementinspect_react_appscrape_pagetest_dropdown_with_error_capturetest_react_appwait_for_elementwait_for_react_stateThe tools have some clear distinctions, such as between scraping, inspecting, and testing functions, but there is significant overlap and ambiguity. For example, 'inspect_element' and 'inspect_react_app' both involve inspection, and 'execute_in_react_context' could be confused with 'test_react_app' or 'wait_for_react_state', making tool selection potentially confusing for an agent.
The naming follows a mostly readable verb_noun pattern, but there are inconsistencies in verb usage and specificity. Tools like 'scrape_page' and 'get_page_info' use different verbs for similar actions, and 'test_dropdown_with_error_capture' includes additional descriptors, deviating from the simpler naming of others like 'wait_for_element'.
With 10 tools, the count is reasonable for a web scraper server that covers scraping, inspection, testing, and waiting functions. It's well-scoped for the domain, though it might be slightly heavy, as some tools could be consolidated to reduce overlap without losing functionality.
The tool set covers core web scraping and testing workflows, including page scraping, element inspection, React app analysis, and interaction testing. Minor gaps exist, such as the lack of tools for handling authentication or advanced data extraction, but agents can likely work around these with the provided tools for most common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Automate cloud browsers to navigate websites, interact with elements, and extract structured data.…
Run multi-step tasks in a real Chrome browser: persistent environments, live view, human takeover.
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/JMRMEDEV/amazon-q-web-scraper-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
