Webtools MCP Server

by misterboe

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.8.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on August 27, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![webtools-mcp-server MCP server](https://glama.ai/mcp/servers/misterboe/webtools-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/misterboe/webtools-mcp-server)

Score Badge

Copy to your README.md:

[![webtools-mcp-server MCP server](https://glama.ai/mcp/servers/misterboe/webtools-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/misterboe/webtools-mcp-server)

Latest Blog Posts

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

MCP directory API

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

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

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