Webby MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have clear distinctions between categories (accessibility, performance, security, SEO) and specific tool implementations (e.g., Axe vs. WAVE), but there is significant overlap in the 'validate_all_' and 'validate_comprehensive' tools, which aggregate other tools and could cause confusion about when to use individual vs. bundled validations. The descriptions help clarify, but the redundancy creates ambiguity in tool selection.
Naming Consistency5/5
All tool names follow a consistent 'validate_' prefix with descriptive suffixes (e.g., 'accessibility_axe', 'performance_pagespeed'), using snake_case uniformly. This predictable pattern makes it easy for agents to understand the purpose and category of each tool at a glance, with no deviations in naming style.
Tool Count4/5
With 12 tools, the count is reasonable for a web validation server covering multiple domains (accessibility, performance, security, SEO), though it feels slightly heavy due to the inclusion of both individual and aggregated tools. The scope is well-defined, and each tool serves a specific purpose, but the aggregation tools add some bulk that might be streamlined.
Completeness5/5
The tool set provides comprehensive coverage for web validation, including multiple tools per category (e.g., three performance tools, two accessibility tools) and aggregated options for broader testing. There are no obvious gaps; agents can perform detailed or holistic validations across all key web quality aspects without dead ends.
Average 3.2/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool runs validation but doesn't mention critical behaviors like execution time, rate limits, authentication needs (implied by API keys in schema but not described), or what 'comprehensive' entails operationally. This is a significant gap for a tool with 8 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by conveying the tool's scope and action, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema, low schema coverage), the description is incomplete. It doesn't address behavioral aspects, parameter usage, or output expectations, leaving the agent with insufficient context to invoke the tool effectively beyond a basic understanding of its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 25%, with only 2 of 8 parameters having descriptions. The description adds minimal value beyond the schema, mentioning 'categories' implicitly but not explaining parameter interactions (e.g., how API keys relate to categories, what 'waitForSSL' does). It fails to compensate for the coverage gap, leaving most parameters poorly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run comprehensive validation across all categories (performance, accessibility, SEO, security).' It specifies the verb ('Run comprehensive validation') and scope ('across all categories'), though it doesn't explicitly differentiate from the many sibling validation tools listed, which focus on specific categories or methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling alternatives (e.g., validate_accessibility_axe, validate_performance_gtmetrix). It mentions 'all categories' but doesn't specify scenarios where this comprehensive approach is preferred over targeted validations, leaving the agent without usage context.
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 the full burden of behavioral disclosure. It mentions the requirement for an API key, which is useful context, but lacks details on rate limits, authentication needs beyond the key, error handling, or what the analysis entails (e.g., is it a one-time scan or continuous?). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: two sentences that directly state the purpose and a key requirement. Every sentence adds value—the first explains what the tool does, and the second notes the API key need. It could be slightly more structured by explicitly listing parameters, but it avoids unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (accessibility analysis tool with 3 parameters, no annotations, and no output schema), the description is incomplete. It lacks details on output format, error cases, performance implications, or how it differs from sibling tools. Without annotations or output schema, the description should provide more context to be fully helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 out of 3 parameters have descriptions). The description adds minimal param semantics: it implies the tool tests 'WCAG compliance, errors, and contrast issues' which relates to the 'url' parameter, but doesn't explain the 'reporttype' enum values (1-4) or provide additional context beyond the schema. With moderate schema coverage, the baseline is 3 as the description doesn't significantly compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze website accessibility using WAVE. Tests WCAG compliance, errors, and contrast issues.' It specifies the verb ('analyze'), resource ('website accessibility'), and method ('using WAVE'), distinguishing it from siblings like 'validate_accessibility_axe' which uses a different tool. However, it doesn't explicitly differentiate from 'validate_all_accessibility' which might also cover accessibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: it mentions 'Requires API key' as a prerequisite, but offers no explicit guidance on when to use this tool versus alternatives like 'validate_accessibility_axe' or 'validate_all_accessibility'. There's no mention of specific scenarios, limitations, or comparisons with sibling tools.
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 the full burden. It mentions running tests but doesn't disclose behavioral traits such as execution time, rate limits, error handling, or what happens if tests fail. For a tool with no annotations and potential external API calls, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and includes key details (Axe + WAVE, API key condition). There is no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running multiple accessibility tests, no annotations, and no output schema, the description is incomplete. It doesn't cover what the tool returns, how results are formatted, or any dependencies like network requirements, leaving the agent with insufficient context for effective 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 67% (2 out of 3 parameters have descriptions), so the baseline is 3. The description adds minimal value beyond the schema by implying that 'waveApiKey' enables WAVE testing, but it doesn't explain parameter interactions or provide additional context for 'wcagLevel' or 'url'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run all accessibility tests') and specifies which tests (Axe + optionally WAVE), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'validate_accessibility_axe' or 'validate_accessibility_wave', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that WAVE is optional if an API key is provided, giving some context, but it lacks explicit guidance on when to use this tool versus alternatives like the individual Axe or WAVE tools, or other comprehensive validation tools. No when-not-to-use scenarios or clear prerequisites are stated.
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 the full burden of behavioral disclosure. It mentions the tool used (PageSpeed Insights with Lighthouse SEO) but doesn't describe key traits like whether it's a read-only operation, potential rate limits, authentication needs, or what the analysis entails (e.g., report format, execution time). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized for its purpose, earning a high score for 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?
Given the tool's complexity (SEO analysis), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what the analysis returns, potential errors, or behavioral aspects, making it inadequate for an agent to fully understand the tool's context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies the parameter is a URL for analysis but doesn't specify format constraints (e.g., must be a valid HTTP/HTTPS URL) or provide any additional semantic details. This adds minimal value beyond what the schema name 'url' suggests, meeting the baseline for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run SEO analysis') and the resource/tool used ('using PageSpeed Insights (includes Lighthouse SEO)'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'validate_comprehensive' or 'validate_all_performance', which might also involve SEO aspects, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'validate_comprehensive' or 'validate_all_performance', nor does it mention any prerequisites or exclusions. It implies usage for SEO analysis but lacks explicit context for tool selection.
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 the full burden of behavioral disclosure. It mentions the API key requirement, which is useful context about authentication needs, but fails to describe what the tool actually does (e.g., runs performance tests, returns metrics like load time/scores), potential rate limits, whether it's a read-only analysis or has side effects, or what the output looks like. This leaves significant gaps for a tool with 4 parameters.
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 brief and front-loaded with the core purpose, consisting of two efficient sentences. However, the second sentence about the API key could be integrated more smoothly, and there's room to add crucial behavioral details without sacrificing 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?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks essential details: what the analysis entails, typical outputs (e.g., performance scores, recommendations), error handling, or how it differs from sibling tools. This makes it inadequate for an agent to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 75% (3 of 4 parameters have descriptions), providing a solid baseline. The description adds minimal value beyond the schema—it implies 'url' and 'apiKey' are needed but doesn't explain parameter interactions or provide examples beyond what's in the schema descriptions. This meets the baseline for adequate but not exceptional coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Analyze') and resource ('website performance using GTmetrix'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling performance tools (validate_performance_pagespeed, validate_performance_webpagetest), which would require specifying what makes GTmetrix analysis unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that an API key is required and notes a free tier is available, which provides some basic context. However, it offers no guidance on when to choose this tool over the other performance validation siblings (pagespeed, webpagetest) or when to prefer this versus comprehensive tools like validate_all_performance or validate_comprehensive.
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 burden for behavioral disclosure. It mentions the tools involved (PageSpeed Insights, WebPageTest, GTmetrix) but doesn't describe what 'run' entails—whether it's synchronous/asynchronous, what outputs to expect, rate limits, authentication needs beyond API keys, or error handling. For a multi-tool integration with 5 parameters, this leaves significant behavioral gaps.
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, efficient sentence that front-loads the core purpose. Every word contributes to understanding the tool's scope, though it could be slightly more structured (e.g., clarifying the relationship between parameters and test execution).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running multiple performance tools with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what results to expect, how failures are handled, or the operational impact (e.g., timeouts, costs). For a tool that likely produces rich performance data, this leaves too much undefined.
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 80%, providing a solid baseline. The description adds minimal value beyond the schema—it implies that parameters control which optional tests are run (WebPageTest, GTmetrix) but doesn't explain interactions (e.g., if 'webpagetestEnabled' is false, does it skip WebPageTest entirely?). No additional syntax or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run all available performance tests') and specifies the resources (PageSpeed Insights, WebPageTest, GTmetrix). It distinguishes from siblings by focusing on comprehensive performance testing rather than individual tools or other validation types like accessibility/security. However, it doesn't explicitly differentiate from 'validate_comprehensive' which might also include performance.
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 context by mentioning 'all available performance tests' and optional components, suggesting this is for comprehensive performance assessment. However, it provides no explicit guidance on when to use this versus sibling tools like 'validate_performance_pagespeed' or 'validate_comprehensive', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 discloses behavioral traits like 'Free, open-source' and 'finds ~57% of WCAG issues with zero false positives,' which adds context on cost and accuracy. However, it lacks critical details such as rate limits, authentication needs, error handling, or what the analysis entails (e.g., runtime, output format). For a tool with no annotations, this is a significant gap in behavioral disclosure.
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 highly concise and front-loaded, consisting of a single sentence that efficiently conveys key information: purpose, technology, cost, and performance metrics. Every part earns its place without redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (accessibility analysis with parameters), no annotations, no output schema, and moderate schema coverage, the description is incomplete. It lacks details on output format, error cases, prerequisites, or how results are returned, which are crucial for an agent to use the tool effectively. The description provides basic context but falls short of being fully informative.
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 50% (one parameter has a description, one does not). The description adds no specific parameter information beyond what the schema provides; it doesn't explain the 'url' or 'wcagLevel' parameters. Since schema coverage is moderate, the description doesn't compensate for the undocumented parameter, resulting in a baseline score of 3 for minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze website accessibility using Axe' specifies the verb (analyze) and resource (website accessibility) with the technology (Axe). It distinguishes from siblings by mentioning 'Free, open-source' and 'finds ~57% of WCAG issues with zero false positives,' which differentiates it from other validation tools, though not explicitly naming alternatives. However, it doesn't fully specify scope (e.g., vs. validate_accessibility_wave), keeping it from a perfect 5.
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 accessibility analysis with Axe, but provides no explicit guidance on when to use this tool versus alternatives like validate_accessibility_wave or validate_all_accessibility. It mentions 'Free, open-source' and performance metrics, which hint at context, but lacks clear when/when-not statements or named alternatives, leaving usage somewhat ambiguous.
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 running tests but lacks details on behavioral traits such as execution time, rate limits, authentication needs, or what happens during 'waitForSSL'. This is inadequate for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized, making it easy to parse without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It does not cover return values, error handling, or tool behavior, leaving significant gaps for a security testing tool with multiple parameters.
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 67% (2 out of 3 parameters have descriptions). The description does not add meaning beyond the schema, as it does not explain parameter roles or interactions. With moderate schema coverage, the baseline is 3, but it fails to compensate for the undocumented 'url' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and the resource 'all security tests', specifying which tests (Mozilla Observatory + SSL Labs). It distinguishes from sibling tools like 'validate_security_mozilla_observatory' and 'validate_security_ssl_labs' by indicating it runs both, but could be more specific about scope or integration.
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 security testing, but does not explicitly state when to use this tool versus alternatives like individual security tools or the comprehensive 'validate_comprehensive'. No guidance on prerequisites or exclusions is provided, leaving context inferred.
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 provided, the description carries the full burden of behavioral disclosure. It adds useful context: 'Free API, 1 scan per minute per domain' informs about cost and rate limits, and 'Analyze HTTP security headers' implies a read-only operation. However, it doesn't detail error handling, response format, or what happens during a scan (e.g., timeouts, retries), leaving gaps for a tool with no output schema.
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 appropriately sized with two sentences: the first states the purpose, and the second adds behavioral context. It's front-loaded with the core function, and each sentence adds value without redundancy. However, it could be slightly more structured by explicitly separating usage guidelines.
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 no annotations, no output schema, and 2 parameters with 50% schema coverage, the description is moderately complete. It covers the tool's purpose and some behavioral traits (rate limits, cost) but lacks details on parameters, return values, and error handling. For a security analysis tool, this leaves significant gaps in understanding how to use it effectively.
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 50% (only 'forceRescan' has a description). The description adds no parameter-specific information beyond what the schema provides. It mentions 'domain' in the rate limit context, which loosely relates to the 'url' parameter but doesn't explain format or constraints. With low coverage, the description fails to compensate, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze HTTP security headers using Mozilla Observatory. Tests CSP, HSTS, etc.' It specifies the verb ('analyze'), resource ('HTTP security headers'), and method ('Mozilla Observatory'), distinguishing it from sibling tools like validate_security_ssl_labs. However, it doesn't explicitly differentiate from other security tools beyond mentioning the specific focus on headers.
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 provides some implied usage context by mentioning 'Free API, 1 scan per minute per domain,' which suggests rate limits and when to use it for scanning. However, it lacks explicit guidance on when to choose this tool over alternatives like validate_security_ssl_labs or validate_all_security, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the free tier limit ('Free 300 tests/month'), the immediate vs. waiting behavior ('Returns test ID immediately or waits for full results'), and the automation method ('via browser automation'). It doesn't cover error handling, rate limits beyond the monthly cap, or authentication needs, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured in three sentences. The first sentence states the core purpose, the second provides important constraints (free tier), and the third explains the key behavioral choice. Every sentence earns its place with zero waste, and information is front-loaded appropriately.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the purpose, constraints, and key behavior but doesn't explain what the output looks like (test ID format, result structure) or potential error conditions. Given the complexity and lack of structured output documentation, there are clear gaps in 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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the waitForResults behavior generally but doesn't elaborate on parameter semantics. The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze website performance using WebPageTest via browser automation.' It specifies the verb (analyze), resource (website performance), and method (WebPageTest via browser automation). However, it doesn't explicitly distinguish this tool from its sibling performance tools like 'validate_performance_gtmetrix' or 'validate_performance_pagespeed' beyond mentioning WebPageTest specifically.
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 provides some usage context with 'Free 300 tests/month' and mentions the waitForResults behavior, but it doesn't explicitly state when to use this tool versus alternatives like validate_performance_gtmetrix or validate_performance_pagespeed. The guidance is implied rather than explicit, lacking clear when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses the tool's long-running nature ('may take minutes'), which is crucial for agent planning. However, it doesn't mention authentication requirements (email parameter is documented in schema but not explained in description), rate limits, or what happens during the wait period.
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 perfectly concise with three short sentences that each earn their place: first states core purpose, second adds scope detail, third provides crucial behavioral warning. No wasted words and front-loaded with the essential action.
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?
For a 6-parameter tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the core purpose and a critical behavioral trait (long-running), but lacks information about return values, error conditions, or how results are structured. The high schema coverage helps, but more context would be beneficial given the complexity.
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 high at 83%, so the baseline is 3. The description doesn't add any parameter-specific information beyond what's in the schema (all 6 parameters are documented in schema with descriptions for 5 of them). No additional syntax, format, or usage details are provided in the description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze SSL/TLS configuration using SSL Labs' with specific mention of 'comprehensive certificate and protocol analysis.' It distinguishes from security siblings by specifying SSL Labs as the analysis engine, but doesn't explicitly contrast with validate_security_mozilla_observatory or other security tools.
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 provides implied usage guidance through 'Long-running (may take minutes)' which suggests when to expect delays, but doesn't explicitly state when to use this vs. alternatives like validate_security_mozilla_observatory or validate_all_security. No explicit when-not-to-use or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's an analysis tool (implied non-destructive), mentions the free API with rate limits ('25K requests/day'), and notes optional authentication ('Optional API key for higher quota'). This covers important behavioral aspects like rate limits and auth needs, though it could add more on error handling or response format.
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 highly concise and front-loaded, with two sentences that efficiently convey purpose, return values, and key behavioral traits (API quota and optional key). Every sentence earns its place without redundancy, making it easy for an agent to parse quickly.
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 the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, return values, and behavioral aspects like rate limits and auth. However, it lacks details on output structure or error cases, which could be helpful for an agent invoking the tool without an output 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 description coverage is 100%, so the schema already documents all parameters (url, strategy, apiKey). The description adds minimal value beyond the schema, mentioning the API key's purpose for higher quota, but does not provide additional semantics like URL formatting or strategy implications. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Analyze website performance') and resource ('using Google PageSpeed Insights'), distinguishing it from sibling tools like validate_performance_gtmetrix or validate_performance_webpagetest by specifying the exact service used. It also mentions the return values ('Core Web Vitals and performance scores'), which helps differentiate its purpose.
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 analysis with PageSpeed Insights but does not explicitly state when to use this tool versus alternatives like validate_performance_gtmetrix or validate_all_performance. It mentions the free API quota, which provides some context, but lacks clear guidance on exclusions or specific scenarios for choosing this tool over siblings.
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:

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

Score Badge

Copy to your README.md:

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

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/cordlesssteve/webby-mcp'

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