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., "@Webtools MCP Server Analyze the performance of https://example.com"
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.
⚠️ IMPORTANT DISCLAIMER: This software has been developed with the assistance of AI technology. It is provided as-is and should NOT be used in production environments without thorough testing and validation. The code may contain errors, security vulnerabilities, or unexpected behavior. Use at your own risk for research, learning, or development purposes only.
A Model Context Protocol server providing comprehensive web analysis tools including HTML extraction, markdown conversion, screenshot capabilities, debug console, advanced performance analysis, and Lighthouse-powered web audits for performance, accessibility, SEO, and more.
Node.js: Version 14 or higher
Chrome/Chromium: Automatically provided by Puppeteer
The server will use Puppeteer's bundled Chrome
No need to install Chrome separately
Related MCP server: Hyperbrowser MCP Server
webtool_gethtml: Raw HTML content extraction
JavaScript rendering support
Proxy support
Automatic retries
webtool_readpage: Markdown conversion
Clean content extraction
Link preservation
Image handling
Custom selector support
webtool_screenshot: Screenshot capture
Full page screenshots
Element-specific capture
Device emulation
Custom viewport settings
webtool_debug: Debug console
Console output capture
Network request monitoring
Error tracking
Performance metrics
Layout thrashing detection
webtool_lighthouse: Comprehensive Web Audit
Performance analysis
Accessibility testing
SEO evaluation
Best practices review
Progressive Web App assessment
Device emulation support
webtool_performance_trace: Advanced Performance Analysis
Layout thrashing detection
CSS variables impact analysis
JavaScript execution timeline with layout correlation
Long task breakdown and attribution
Memory and DOM size analysis
Resource loading optimization
webtool_network_monitor: Network Activity Analysis
Detailed request and response analysis
Resource timing information
Waterfall visualization data
Optimization recommendations
Third-party request analysis
Cache analysis
webtool_coverage_analysis: Code Coverage Analysis
JavaScript and CSS coverage analysis
Unused code identification
Code splitting recommendations
Third-party code analysis
webtool_web_vitals: Core Web Vitals Analysis
LCP (Largest Contentful Paint) analysis
CLS (Cumulative Layout Shift) analysis
FID/INP (First Input Delay/Interaction to Next Paint) analysis
TTFB (Time to First Byte) analysis
Element-specific analysis
webtool_performance_test: Cross-device and Network Testing
Multi-device testing
Network condition simulation
Comparative analysis
Baseline comparison
Device-specific recommendations
analyze-website: Comprehensive Website Analysis
Performance, accessibility, SEO, and UX analysis
Device type selection (mobile/desktop)
Detailed recommendations tailored to device type
Complete analysis report with actionable insights
get-website-content: Content Extraction
Main content extraction from any webpage
Clean markdown conversion
Removal of navigation, ads, and non-essential elements
Preservation of important formatting and structure
screenshot-website: Screenshot Capture
Visual representation of webpage
Full page capture
Simple URL-based interface
technical-performance-analysis: Technical Performance Analysis
Detailed technical analysis of performance bottlenecks
Code examples and optimization suggestions
Focus area selection (JavaScript, rendering, resources, network)
Performance metrics with severity assessment
Actionable, code-level recommendations
You can install the package globally:
npm install -g @bschauer/webtools-mcp-serverOr use it directly with npx:
npx @bschauer/webtools-mcp-server{
"mcpServers": {
"webtools": {
"command": "npx",
"args": ["-y", "@bschauer/webtools-mcp-server@latest"],
"env": {
"ENABLED_TOOLS": "BASIC"
}
}
}
}This configuration uses only basic tools and reduces token usage by 89%.
# Install with token optimization
claude mcp add webtools-basic --env ENABLED_TOOLS=BASIC -- npx -y @bschauer/webtools-mcp-server@latestOnce configured, you can ask Claude:
"Please extract the main content from https://example.com"
"Take a screenshot of https://google.com"
"Analyze the performance of https://news.ycombinator.com"
By default, all tools are loaded (~10.3k tokens). You can reduce token usage by enabling only the tools you need:
Environment Variable: ENABLED_TOOLS=<preset|tools>
CLI Argument: --tools=<preset|tools>
Preset | Tools Included | Token Usage | Reduction | Use Case |
| All 10 tools | ~10.3k tokens | 0% | Full functionality (default) |
|
| ~1k tokens | 89% | Content extraction only |
|
| ~1.5k tokens | 85% | Web content + visuals |
|
| ~2.5k tokens | 76% | Content + debugging |
| All performance analysis tools | ~6k tokens | 42% | Performance testing only |
| All tools except performance test framework | ~9k tokens | 13% | Complete analysis suite |
Individual Tools Available:
webtool_gethtml - Raw HTML extraction
webtool_readpage - Markdown conversion
webtool_screenshot - Screenshot capture
webtool_debug - Debug console + network monitoring
webtool_lighthouse - Lighthouse audits
webtool_performance_trace - Performance tracing
webtool_coverage_analysis - Code coverage analysis
webtool_web_vitals - Core Web Vitals metrics
webtool_network_monitor - Network activity analysis
webtool_performance_test - Cross-device performance testing
# Use only basic tools (90% token reduction)
ENABLED_TOOLS=BASIC npx @bschauer/webtools-mcp-server
# Use performance tools only
npx @bschauer/webtools-mcp-server --tools=PERFORMANCE
# Use web + debugging tools
ENABLED_TOOLS=DEBUG npx @bschauer/webtools-mcp-server
# Use specific individual tools
npx @bschauer/webtools-mcp-server --tools=webtool_gethtml,webtool_readpage,webtool_screenshot
# Show all available options
npx @bschauer/webtools-mcp-server --help
# Use environment variable with any command
export ENABLED_TOOLS=WEB
npx @bschauer/webtools-mcp-server{
"mcpServers": {
"webtools": {
"command": "npx",
"args": ["-y", "@bschauer/webtools-mcp-server@latest"]
}
}
}Basic Tools Only (89% Token Reduction)
{
"mcpServers": {
"webtools-basic": {
"command": "npx",
"args": ["-y", "@bschauer/webtools-mcp-server@latest"],
"env": {
"ENABLED_TOOLS": "BASIC"
}
}
}
}Web Content + Screenshots
{
"mcpServers": {
"webtools-web": {
"command": "npx",
"args": ["-y", "@bschauer/webtools-mcp-server@latest"],
"env": {
"ENABLED_TOOLS": "WEB"
}
}
}
}Performance Analysis Only
{
"mcpServers": {
"webtools-perf": {
"command": "npx",
"args": ["-y", "@bschauer/webtools-mcp-server@latest"],
"env": {
"ENABLED_TOOLS": "PERFORMANCE"
}
}
}
}Custom Tool Selection
{
"mcpServers": {
"webtools-custom": {
"command": "npx",
"args": ["-y", "@bschauer/webtools-mcp-server@latest"],
"env": {
"ENABLED_TOOLS": "webtool_gethtml,webtool_readpage,webtool_screenshot,webtool_debug"
}
}
}
}Using CLI Arguments (Alternative)
{
"mcpServers": {
"webtools": {
"command": "npx",
"args": ["-y", "@bschauer/webtools-mcp-server@latest", "--tools=BASIC"]
}
}
}Claude Code provides a simplified command-line interface for adding MCP servers:
# Install with all tools (default)
claude mcp add webtools -- npx -y @bschauer/webtools-mcp-server@latest# Basic tools only (89% token reduction)
claude mcp add webtools-basic --env ENABLED_TOOLS=BASIC -- npx -y @bschauer/webtools-mcp-server@latest
# Web content + screenshots
claude mcp add webtools-web --env ENABLED_TOOLS=WEB -- npx -y @bschauer/webtools-mcp-server@latest
# Performance analysis only
claude mcp add webtools-perf --env ENABLED_TOOLS=PERFORMANCE -- npx -y @bschauer/webtools-mcp-server@latest
# Debug tools
claude mcp add webtools-debug --env ENABLED_TOOLS=DEBUG -- npx -y @bschauer/webtools-mcp-server@latest
# Custom tool selection
claude mcp add webtools-custom --env ENABLED_TOOLS=webtool_gethtml,webtool_readpage,webtool_screenshot -- npx -y @bschauer/webtools-mcp-server@latest# Using --tools parameter instead of environment variable
claude mcp add webtools-basic -- npx -y @bschauer/webtools-mcp-server@latest --tools=BASIC
claude mcp add webtools-perf -- npx -y @bschauer/webtools-mcp-server@latest --tools=PERFORMANCE# List all MCP servers
claude mcp list
# Get details about the webtools server
claude mcp get webtools-basic
# Remove a server
claude mcp remove webtools-basic
# Check server status in Claude Code
/mcp# Install for the entire project team
claude mcp add webtools-basic --scope project --env ENABLED_TOOLS=BASIC -- npx -y @bschauer/webtools-mcp-server@latest
# This creates a .mcp.json file in your project root that can be committed to version controlCreate a configuration file at ~/.mcp/webtools-mcp-server.config.json:
{
"proxy": {
"enabled": false,
"url": "http://your-proxy-server:port",
"timeout": 10000
},
"browser": {
"ignoreSSLErrors": false,
"defaultViewport": {
"width": 1920,
"height": 1080
}
},
"devices": {
"mobile": {
"width": 375,
"height": 812,
"deviceScaleFactor": 3,
"isMobile": true,
"hasTouch": true,
"isLandscape": false,
"userAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Mobile/15E148 Safari/604.1"
},
"tablet": {
"width": 768,
"height": 1024,
"deviceScaleFactor": 2,
"isMobile": true,
"hasTouch": true,
"isLandscape": false,
"userAgent": "Mozilla/5.0 (iPad; CPU OS 15_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Mobile/15E148 Safari/604.1"
},
"desktop": {
"width": 1920,
"height": 1080,
"deviceScaleFactor": 1,
"isMobile": false,
"hasTouch": false,
"isLandscape": true,
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
}
},
"networkConditions": {
"Slow 3G": {
"downloadThroughput": 500000,
"uploadThroughput": 300000,
"latency": 400
},
"Fast 3G": {
"downloadThroughput": 1500000,
"uploadThroughput": 750000,
"latency": 300
},
"4G": {
"downloadThroughput": 4000000,
"uploadThroughput": 2000000,
"latency": 100
},
"WiFi": {
"downloadThroughput": 10000000,
"uploadThroughput": 5000000,
"latency": 20
},
"Fiber": {
"downloadThroughput": 100000000,
"uploadThroughput": 50000000,
"latency": 5
}
}
}You can also configure the server using environment variables:
USE_PROXY: Enable proxy support (true/false)
PROXY_URL: Proxy server URL
PROXY_TIMEOUT: Proxy timeout in milliseconds
IGNORE_SSL_ERRORS: Ignore SSL certificate errors by default for all tools (true/false) - useful for development environments like DDEV
webtool_gethtml({
url: "https://example.com",
useJavaScript: true,
useProxy: false,
ignoreSSLErrors: false,
});webtool_readpage({
url: "https://example.com",
useJavaScript: true,
useProxy: false,
selector: "main",
ignoreSSLErrors: false,
});webtool_screenshot({
url: "https://example.com",
selector: ".content",
useProxy: false,
deviceConfig: {
width: 1920,
height: 1080,
deviceScaleFactor: 1,
isMobile: false,
},
});webtool_debug({
url: "https://example.com",
captureConsole: true,
captureNetwork: true,
captureErrors: true,
captureLayoutThrashing: true, // Enable layout thrashing detection
timeoutMs: 15000,
});// Focus on layout thrashing detection
webtool_debug({
url: "https://example.com",
captureConsole: false,
captureNetwork: false,
captureErrors: true,
captureLayoutThrashing: true,
timeoutMs: 15000,
});webtool_lighthouse({
url: "https://example.com",
categories: ["performance", "accessibility", "best-practices", "seo", "pwa"],
device: "mobile", // or "desktop"
ignoreSSLErrors: false,
});// Run specific category audits only
webtool_lighthouse({
url: "https://example.com",
categories: ["performance", "seo"], // Only performance and SEO
device: "desktop",
});webtool_performance_trace({
url: "https://example.com",
timeoutMs: 15000,
captureCPUProfile: true,
captureNetworkActivity: true,
captureJSProfile: true,
captureRenderingPerformance: true,
captureMemoryProfile: true,
deviceConfig: {
width: 1920,
height: 1080,
deviceScaleFactor: 1,
isMobile: false,
},
});// Focus on specific performance aspects
webtool_performance_trace({
url: "https://example.com",
captureRenderingPerformance: true, // Focus on layout and rendering
captureMemoryProfile: true, // Include memory analysis
deviceConfig: {
width: 375,
height: 812,
deviceScaleFactor: 3,
isMobile: true,
},
});webtool_network_monitor({
url: "https://example.com",
timeoutMs: 15000,
waitAfterLoadMs: 2000,
includeThirdParty: true,
disableCache: true,
captureHeaders: true,
captureTimings: true,
deviceName: "mobile", // Use predefined device
networkConditionName: "4G", // Use predefined network condition
});webtool_coverage_analysis({
url: "https://example.com",
timeoutMs: 15000,
waitAfterLoadMs: 2000,
includeThirdParty: true,
disableCache: true,
deviceName: "desktop",
});webtool_web_vitals({
url: "https://example.com",
timeoutMs: 15000,
waitAfterLoadMs: 3000,
interactWithPage: true,
deviceName: "mobile",
networkConditionName: "4G",
});webtool_performance_test({
url: "https://example.com",
timeoutMs: 30000,
devices: ["desktop", "mobile", "tablet"],
networkConditions: ["WiFi", "4G", "3G"],
tests: ["web_vitals", "network", "coverage"],
compareResults: true,
baselineDevice: "desktop",
baselineNetwork: "WiFi",
includeScreenshots: true,
});All tools return responses in the following format:
{
"content": [
{
"type": "text",
"text": "..." // Markdown formatted report
}
]
}For screenshots:
{
"content": [
{
"type": "image",
"data": "...", // Base64 encoded PNG
"mimeType": "image/png"
}
]
}For Lighthouse audits:
{
"content": [
{
"type": "text",
"text": "..." // Markdown formatted report with audit results
}
]
}Start with basic HTML retrieval before using advanced analysis
Use JavaScript rendering only when necessary (slower but more complete)
Set appropriate timeouts for complex pages
Use selectors to target specific page sections when possible
Enable proxy support only when needed for geo-restricted content
For Lighthouse audits, specify only the categories you need to improve performance
Check errors carefully - they often contain helpful troubleshooting tips
When using device emulation, match real device specifications for accurate results
For large websites, focus on specific pages rather than entire sites
Use the debug tool to understand JavaScript errors before applying fixes
For performance testing, start with the baseline device and network condition
Compare results across different devices and network conditions to identify device-specific issues
Use the performance test framework to identify optimization opportunities for specific scenarios
Focus on Core Web Vitals metrics for the best user experience improvements
Use code coverage analysis to identify unused code and optimize bundle size
Common issues and solutions:
Note: Chrome is now automatically installed via Puppeteer - no additional steps required
If you encounter any Chrome-related issues, try reinstalling the package with npm install -g @bschauer/webtools-mcp-server
Issue: Cannot connect to website
Solution: Check URL format, website availability, or try with proxy enabled
Issue: SSL certificate errors with DDEV or local development sites
Solution: Set IGNORE_SSL_ERRORS=true environment variable or use ignoreSSLErrors=true parameter for individual tools
Note: For production sites, ensure proper SSL certificate configuration instead of bypassing SSL checks
Issue: Page content missing when using JavaScript rendering
Solution: Increase timeout, check for navigation errors in debug output
Issue: Blank or incomplete screenshots
Solution: Ensure selectors are correct, increase viewport size, check debug console
Issue: Lighthouse audit times out
Solution: Increase timeout setting, reduce categories, try with a faster connection
Issue: Cannot connect through proxy
Solution: Verify proxy URL, check proxy connection timeout, ensure proxy is operational
Issue: No layout thrashing events detected
Solution: Ensure captureLayoutThrashing is set to true, increase timeoutMs, try with different pages
Issue: Performance test framework times out
Solution: Reduce the number of devices and network conditions, increase timeout, run tests individually
Issue: Network monitor shows incomplete data
Solution: Increase waitAfterLoadMs, ensure captureTimings is set to true, check for CORS issues
Issue: Code coverage analysis shows no results
Solution: Ensure the page loads JavaScript, increase waitAfterLoadMs, check for script loading errors
This tool can access arbitrary websites - use responsibly
The proxy feature should be used with caution and in compliance with applicable laws
SSL certificate checking should remain enabled unless absolutely necessary
Website owners may detect and block automated access
Some websites prohibit scraping in their Terms of Service
Contributions are welcome! Please feel free to submit a Pull Request.
MIT
bschauer
Analyze JavaScript and CSS coverage to identify unused code and optimization opportunities. Uses Chrome DevTools Protocol Coverage API to provide detailed insights into code usage.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to analyze | |
| timeoutMs | No | Timeout in milliseconds for the analysis | |
| waitAfterLoadMs | No | Additional time to wait after page load to capture more interactions | |
| includeThirdParty | No | Whether to include third-party scripts and stylesheets in the analysis | |
| useProxy | No | Whether to use a proxy for this request | |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (use with caution) | |
| disableCache | No | Whether to disable browser cache for the analysis | |
| networkConditionName | No | Predefined network condition to emulate (e.g., 'Slow 3G', 'Fast 3G', '4G', 'WiFi', 'Fiber') | |
| networkCondition | No | Custom network condition configuration | |
| deviceName | No | Predefined device to emulate (e.g., 'Pixel 7', 'iPhone 14') | |
| deviceConfig | No | Custom device configuration for emulation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. While it indicates an analysis (likely read-only), it does not state whether any modifications occur, if authentication is needed, or what side effects (e.g., cache clearing) happen. The assertion 'provides detailed insights' is vague about the nature of the output.
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 two sentences, front-loading the core purpose and underlying technology. No redundant information; every word serves a purpose.
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?
Despite 11 parameters including nested objects and no output schema, the description is extremely brief. It does not explain what the output looks like, how results are structured, or how to interpret the 'detailed insights.' This is insufficient for a complex tool with many configuration options.
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 adds no additional meaning beyond the schema, which is acceptable for a high-coverage case. No augmentation of parameter understanding is provided.
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 that the tool analyzes JavaScript and CSS coverage to identify unused code and optimization opportunities, using the Chrome DevTools Protocol Coverage API. This is a specific verb and resource, and it distinguishes this tool from sibling tools (e.g., performance_test, web_vitals) which focus on different aspects.
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 mentions using the Coverage API but does not explicitly state when to use this tool versus alternatives like performance_test or web_vitals. It lacks guidance on prerequisites or when not to use it, leaving the agent to infer context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Debug a webpage by capturing console output, network requests, errors, and layout thrashing with custom device emulation. Includes advanced response size management with pagination, output limits, and compact formatting to stay within MCP token limits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to debug | |
| captureConsole | No | Capture console.log, warn, error output | |
| captureNetwork | No | Capture network requests and responses | |
| captureErrors | No | Capture JavaScript errors and exceptions | |
| captureLayoutThrashing | No | Capture layout thrashing events (forced layout/reflow) | |
| timeoutMs | No | How long to collect debug information in milliseconds | |
| useProxy | No | Whether to use a proxy for this request | |
| deviceConfig | No | Custom device configuration for emulation | |
| maxConsoleEvents | No | Maximum number of console events to include in the response | |
| maxNetworkEvents | No | Maximum number of network events to include in the response | |
| maxErrorEvents | No | Maximum number of error events to include in the response | |
| maxResourceEvents | No | Maximum number of resource timing events to include in the response | |
| skipStackTraces | No | Skip stack traces in layout thrashing events to reduce response size | |
| compactFormat | No | Use compact format for all sections to reduce response size | |
| summarizeOnly | No | Include only summary and counts without detailed event data | |
| page | No | Page number for paginated results (starts at 1) | |
| pageSize | No | Number of events per page for paginated results | |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (default: true for development convenience) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions capturing output and token limits but does not disclose potential side effects like webpage loading, auth requirements, or rate limits.
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?
Two sentences efficiently front-load the core purpose and key features without redundancy or fluff.
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 18 parameters, nested objects, and no output schema, the description provides adequate overview but lacks behavioral and usage details needed for complete agent understanding.
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 detailed parameter descriptions, so the description adds limited additional meaning beyond mentioning pagination and compact formatting.
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 debugs webpages by capturing console output, network requests, errors, and layout thrashing, and distinguishes itself from sibling tools with its comprehensive debugging focus and advanced response management features.
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 siblings like webtool_network_monitor or webtool_performance_test. The description only mentions what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the HTML content of a webpage. Automatically handles retries and proxy if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to fetch | |
| useJavaScript | No | Whether to execute JavaScript (requires Puppeteer) | |
| useProxy | No | Whether to use a proxy for this request | |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (default: true for development convenience) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions automatic retries and proxy handling, which is helpful, but fails to disclose failure behavior, rate limits, or any other side effects. The behavioral disclosure is minimal.
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 is concise and front-loaded, containing all relevant information without 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?
With four parameters and no output schema or annotations, the description covers basic function and automatic behaviors like retries and proxy. However, it omits details about the return format and does not address the ignoreSSLErrors default behavior mentioned in the 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% with each parameter already described. The description adds no additional meaning beyond what the schema provides, earning a baseline score of 3.
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 'Get the HTML content of a webpage' using a specific verb and resource. It mentions additional features like automatic retries and proxy handling, which distinguishes it from sibling tools like webtool_screenshot or webtool_readpage.
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 guidance is provided on when to use this tool versus alternatives such as webtool_readpage or webtool_debug. The description only implies it is for fetching HTML with retries and proxy support, but does not clarify contexts where other tools are more suitable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Lighthouse audit on a webpage to generate a comprehensive performance report with detailed resource analysis. The report includes specific file paths, resource sizes, and performance metrics similar to Chrome DevTools. Identifies exact files causing performance issues without offering improvement suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to audit | |
| categories | No | Categories to include in the audit | |
| device | No | Device to emulate | mobile |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (default: true for development convenience) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that the tool generates a report and identifies files without offering suggestions, implying a read-only operation. However, it does not mention performance impact, data retention, or cancellation behavior, which would be expected for a full-featured audit tool.
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 two sentences with no redundant information. The first sentence accurately states the action and result; the second adds valuable detail about output precision. 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 4 parameters (all documented in schema), no output schema, and no annotations, the description provides a solid understanding of the tool's output and limitations. It lacks only minor details like typical execution time and error handling, but overall it is sufficient for initial 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 100%, so parameters are already well-documented. The description adds general context about the report output but does not deepen understanding of specific parameters (e.g., why choose 'mobile' vs 'desktop' or which categories matter). Baseline 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 tool's purpose: running a Lighthouse audit on a webpage to generate a comprehensive performance report. It specifies the exact output (file paths, resource sizes, metrics) and highlights what the tool does not do (offer improvement suggestions), setting it apart from siblings like webtool_performance_test.
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 guidance on when to use this tool versus alternatives. The description does not mention context, prerequisites, or when not to use. Sibling tools exist (e.g., webtool_performance_test, webtool_web_vitals), but no differentiation criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze network activity and resource loading performance. Provides detailed insights into network requests, timing, and optimization opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to analyze | |
| timeoutMs | No | Timeout in milliseconds for the analysis | |
| waitAfterLoadMs | No | Additional time to wait after page load to capture more requests | |
| useProxy | No | Whether to use a proxy for this request | |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (use with caution) | |
| includeThirdParty | No | Whether to include third-party requests in the analysis | |
| disableCache | No | Whether to disable browser cache for the analysis | |
| captureHeaders | No | Whether to capture request and response headers | |
| captureContent | No | Whether to capture request and response content | |
| captureTimings | No | Whether to capture detailed timing information | |
| filterByType | No | Filter requests by resource type (e.g., 'document', 'stylesheet', 'script', 'image', 'font', 'media', 'json', 'text') | |
| filterByDomain | No | Filter requests by domain (e.g., 'example.com') | |
| sortBy | No | Sort requests by a specific property | startTime |
| networkConditionName | No | Predefined network condition to emulate (e.g., 'Slow 3G', 'Fast 3G', '4G', 'WiFi', 'Fiber') | |
| networkCondition | No | Custom network condition configuration | |
| deviceName | No | Predefined device to emulate (e.g., 'Pixel 7', 'iPhone 14') | |
| deviceConfig | No | Custom device configuration for emulation | |
| maxRequests | No | Maximum number of requests to include in the response (to limit response size) | |
| summarizeOnly | No | Whether to include only summary and recommendations without detailed request data (to reduce response size) | |
| page | No | Page number for paginated results (starts at 1) | |
| pageSize | No | Number of requests per page for paginated results | |
| includeRecommendations | No | Whether to include optimization recommendations in the output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only describes it as an analysis tool with no mention of side effects, required permissions, or whether it modifies state. It implies a read-only operation but does not explicitly confirm safety.
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?
Two sentences, concise, and front-loaded with the main action. However, it lacks structure such as bullet points or sectioning, but is still efficient.
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 22 parameters, nested objects, and no output schema, the description is insufficient. It does not explain how results are returned, pagination, or output format. For a complex tool, more context 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 coverage is 100%, and each parameter has a description in the schema. The tool description adds no extra meaning beyond the schema. Baseline 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 it analyzes network activity and resource loading performance. It provides insights into network requests, timing, and optimization. However, it does not differentiate itself from sibling tools like webtool_performance_test or webtool_lighthouse, which also involve performance 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?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites, contexts where it is appropriate, or when to avoid using it. Sibling tools are not mentioned or contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run performance tests across different devices and network conditions. Compare results and identify device-specific or network-specific issues.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to test | |
| timeoutMs | No | Timeout in milliseconds for each test | |
| waitAfterLoadMs | No | Additional time to wait after page load for each test | |
| useProxy | No | Whether to use a proxy for this request | |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (use with caution) | |
| devices | No | Devices to test on | |
| networkConditions | No | Network conditions to test with | |
| tests | No | Tests to run | |
| compareResults | No | Whether to compare results between different scenarios | |
| baselineDevice | No | Device to use as baseline for comparison | desktop |
| baselineNetwork | No | Network condition to use as baseline for comparison | WiFi |
| includeScreenshots | No | Whether to include screenshots in the results | |
| runMultipleTimes | No | Whether to run each test multiple times to get more accurate results | |
| numberOfRuns | No | Number of runs to perform for each test if runMultipleTimes is true |
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 what the tool does, not side effects, resource consumption, or whether it modifies state. It lacks details on rate limits, auth needs, or destructiveness.
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 two sentences, front-loaded with the core purpose. Every sentence adds value, with no extraneous text.
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 14 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain the comparison logic, return format, or how multiple runs work. A more detailed description is needed for such a complex 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 description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it mentions 'devices' and 'network conditions' generically, but doesn't elaborate on allowed values or usage nuances.
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: running performance tests across multiple devices and network conditions and comparing results. It distinguishes itself from siblings like webtool_lighthouse (Lighthouse audit) and webtool_web_vitals (vitals only) by focusing on cross-device/network comparison.
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 usage for performance testing across devices/networks, but does not explicitly state when to use this tool over alternatives (e.g., webtool_lighthouse or webtool_web_vitals). No guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a detailed performance analysis with specialized modules for layout thrashing, CSS variables impact, JavaScript execution timeline, long tasks breakdown, memory and DOM growth analysis, and resource loading optimization. Provides actionable recommendations for performance improvements.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to analyze | |
| timeoutMs | No | Timeout in milliseconds for the analysis | |
| captureCPUProfile | No | Whether to capture CPU profile to identify JavaScript bottlenecks | |
| captureNetworkActivity | No | Whether to capture detailed network requests and timing | |
| captureJSProfile | No | Whether to capture JavaScript execution profile | |
| captureRenderingPerformance | No | Whether to capture rendering performance metrics (layout shifts, layer tree) | |
| captureMemoryProfile | No | Whether to capture memory usage profile | |
| useProxy | No | Whether to use a proxy for this request | |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (use with caution) | |
| analyzeLayoutThrashing | No | Whether to analyze layout thrashing patterns | |
| analyzeCssVariables | No | Whether to analyze CSS variables impact | |
| analyzeJsExecution | No | Whether to analyze JavaScript execution and its correlation with layout events | |
| analyzeLongTasks | No | Whether to analyze long tasks and their attribution | |
| analyzeMemoryAndDom | No | Whether to analyze memory usage and DOM growth | |
| analyzeResourceLoading | No | Whether to analyze resource loading waterfall | |
| longTaskThresholdMs | No | Threshold in milliseconds for long tasks detection | |
| layoutThrashingThreshold | No | Threshold for layout thrashing detection (number of layout operations) | |
| memoryLeakThresholdKb | No | Threshold in KB/s for memory leak detection | |
| detailLevel | No | Level of detail in the analysis output | detailed |
| includeRecommendations | No | Whether to include optimization recommendations in the output | |
| focusSelector | No | CSS selector to focus the analysis on specific DOM elements | |
| focusTimeRangeMs | No | Time range in milliseconds to focus the analysis (format: 'start-end', e.g., '0-5000') | |
| deviceConfig | No | Device configuration for emulation |
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 analysis modules and actionable recommendations but does not disclose whether the tool modifies the page (likely read-only from 'trace' in name), potential side effects, or required permissions. The behavioral profile is partially inferred but not explicit.
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, moderately long sentence that covers the main modules and value proposition. It is not excessively long but lacks structured breakdown like bullet points or sectioning. It could be more front-loaded with the primary purpose.
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 (23 parameters, nested objects) and no output schema, the description provides a high-level overview but omits details on output format, pagination, or error handling. It mentions 'actionable recommendations' but does not specify the structure or depth of the analysis results.
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 an overall context but does not explain individual parameters beyond what the schema already provides. The specialization modules listed in the description correspond directly to boolean parameters already present in 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 performs detailed performance analysis and lists specific specialized modules (layout thrashing, CSS variables, etc.). It effectively distinguishes from sibling tools like 'webtool_performance_test' or 'webtool_web_vitals' by focusing on trace-level diagnostics.
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 gives a clear overview of what the tool does but does not explicitly state when to use this tool versus alternatives like 'webtool_lighthouse' or 'webtool_performance_test'. No when-not-to-use guidance is provided, though the modules imply suitability for in-depth performance debugging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the webpage content in Markdown format, including links and images. Handles blocked access automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to fetch | |
| useJavaScript | No | Whether to execute JavaScript (requires Puppeteer) | |
| useProxy | No | Whether to use a proxy for this request | |
| selector | No | Optional CSS selector to extract specific content (e.g., 'main', 'article') | body |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (default: true for development convenience) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavioral trait of handling blocked access automatically, which adds value, but does not cover other important behaviors like rate limits, robots.txt compliance, or conversion quality, which are left implicit.
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?
Two sentences, each with specific information: one on output format and one on automatic handling. No redundancy or wasted 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?
Despite full schema coverage, the description lacks details about the Markdown conversion process, error handling, and precisely what 'handles blocked access' means. Adequate but not comprehensive.
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 does not add extra parameter-level information 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 webpage content in Markdown format, including links and images, which distinguishes it from siblings like webtool_gethtml (likely raw HTML) and webtool_screenshot (visual).
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 usage for obtaining Markdown content and mentions automatic handling of blocked access, but does not explicitly state when to use this tool versus alternatives, nor provide when-not scenarios.
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 a webpage or specific element on the page with custom device emulation
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to screenshot | |
| selector | No | Optional CSS selector to screenshot a specific element | |
| useProxy | No | Whether to use a proxy for this request | |
| deviceConfig | No | Custom device configuration for emulation | |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (default: true for development convenience) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions 'screenshot' and 'custom device emulation' which are key behaviors, but lacks disclosure on potential side effects (e.g., page loading, resource consumption) or idempotency. Since no annotations, description carries full burden; it adds some context but not complete.
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, 16 words, front-loaded with verb and resource. No wasted words, but could include more details without losing 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?
Despite having 5 parameters including a nested object, the description is minimal. No mention of output format (e.g., returns an image/binary), proxy usage, SSL handling, or required permissions. Given no output schema, more detail needed for 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 descriptions cover all 5 parameters fully (100% coverage). Description adds no additional meaning beyond the high-level purpose; the mention of 'specific element' echoes the selector parameter already described in schema. Baseline 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?
Description clearly states 'Take a screenshot' with specific target ('webpage or specific element') and custom device emulation. Distinguishes from sibling tools like webtool_readpage which reads content, and webtool_gethtml which gets HTML.
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 vs alternatives like webtool_readpage or webtool_debug. Does not mention when not to use, prerequisites, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze Core Web Vitals metrics (LCP, CLS, FID/INP, TTFB) and identify problematic elements affecting these metrics. Uses Performance Observer API to provide detailed insights into real user experience metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the webpage to analyze | |
| timeoutMs | No | Timeout in milliseconds for the analysis | |
| waitAfterLoadMs | No | Additional time to wait after page load to capture more metrics | |
| interactWithPage | No | Whether to automatically interact with the page to trigger more events | |
| useProxy | No | Whether to use a proxy for this request | |
| ignoreSSLErrors | No | Whether to ignore SSL certificate errors (use with caution) | |
| networkConditionName | No | Predefined network condition to emulate (e.g., 'Slow 3G', 'Fast 3G', '4G', 'WiFi', 'Fiber') | |
| networkCondition | No | Custom network condition configuration | |
| deviceName | No | Predefined device to emulate (e.g., 'Pixel 7', 'iPhone 14') | |
| deviceConfig | No | Custom device configuration for emulation | |
| runMultipleTimes | No | Whether to run the analysis multiple times to get more accurate results | |
| numberOfRuns | No | Number of runs to perform if runMultipleTimes is true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It mentions using Performance Observer API and providing insights, implying a non-destructive read operation. However, it omits critical details like whether the tool actually loads the URL (likely yes), potential impact on the server, or any rate limits. The description is adequate but could be more explicit about safety.
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?
Two concise sentences deliver the core purpose and method with zero redundancy. The first sentence focuses on actionable output (identify problematic elements), and the second adds technical credibility. Every word serves a purpose.
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?
Without an output schema, the description must clarify return values. It vaguely promises 'detailed insights' but doesn't specify structure (e.g., list of elements with metrics, scores, or suggestions). Given the tool's complexity (12 params, nested objects), this omission leaves agents uncertain how to use results.
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 need not elaborate each parameter. The description adds context by naming the underlying API (Performance Observer) and the goal of identifying problematic elements, which aids understanding. However, it doesn't enhance parameter meaning beyond the schema's already comprehensive descriptions, earning a baseline 3.
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 analyzes Core Web Vitals metrics and lists specific metrics (LCP, CLS, FID/INP, TTFB), making it distinct from sibling performance tools like webtool_lighthouse which focus on broader audits. The verb 'Analyze' and resource 'Core Web Vitals metrics' are specific and 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 like webtool_lighthouse or webtool_performance_test. The description implies usage for web vitals analysis but lacks explicit context for selection, such as scenarios requiring element-level identification or non-Lighthouse approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, covering different aspects of web analysis: coverage, debugging, HTML retrieval, Lighthouse audit, network, performance testing, performance tracing, reading as markdown, screenshots, and web vitals. Minimal overlap with sufficient differentiation.
All tools use the 'webtool_' prefix followed by a descriptive name (e.g., coverage_analysis, debug, lighthouse). The naming pattern is predictable and consistent, making it easy for agents to infer tool functions.
With 10 tools, the server is well-scoped for its domain of web development analysis. Each tool serves a specific need without redundancy, and the count is neither too small nor excessive.
The tool set covers a comprehensive range of web debugging and performance analysis tasks, including HTML extraction, screenshots, network monitoring, multiple performance metrics, and tracing. It provides a full lifecycle for analyzing web pages.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Read a URL as clean markdown, screenshot a website, url to PDF. Web access for agents, no signup.
8-tool AI web intelligence suite: search, scrape, screenshot, SEO, docs, crypto, code.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/misterboe/webtools-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
