HubVibe Site Audits

Name: HubVibe Site Audits
Author: Its-fortunatefolly

Server Details

Rule-based site audits: accessibility, SEO, security headers, performance. Metered per call.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-21 17:52
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: Its-fortunatefolly/HubVibe
GitHub Stars: 0

TDQS

A4.4/5.0

Scored 2026-09-19 12:30 across 5 tools

Disambiguation5/5

Each tool targets a distinct audit domain: performance, security, SEO, and WCAG accessibility. The audit_bundle tool is clearly a combined aggregate of the others and is named to signal its role, so no ambiguity exists.

Naming Consistency5/5

All tool names follow a strict verb_noun snake_case pattern (audit_<domain>), making them predictable and easy to understand. The consistency is perfect across the entire set.

Tool Count5/5

Five tools is well-scoped for a site audit server: four specialized audits plus a convenient bundle. There are no redundant or unnecessary tools, and the count feels appropriate for the domain.

Completeness5/5

The server covers the major audit categories (accessibility, SEO, security, performance) and provides a bundle for a comprehensive check. No obvious gaps exist in the primary purpose of running website audits, and all tools return actionable results.

Available Tools

5 tools

audit_bundleFull site compliance bundle (all four audits)A

Read-onlyIdempotent

Inspect

Full website audit in one call: accessibility (WCAG 2.1 A/AA via axe-core), on-page SEO, HTTP security headers and page speed / page weight, from a single browser load of one URL. Cheaper than four separate calls; if any part cannot run, nothing is billed. $0.15 per call. Returns: pass (bool) plus wcag{}, seo{}, security{}, performance{} sub-results.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Live, fetchable http(s) URL to audit.

Output Schema

ParametersJSON Schema

Name	Required	Description
`seo`	No
`pass`	Yes	Whether every rule in this dimension passed.
`wcag`	No
`status`	No	Present only on a completed audit.
`security`	No
`performance`	No

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description discloses meaningful behavioral details: a single browser load per URL, a fixed price of $0.15 per call, and the partial-failure policy that 'nothing is billed' if any component cannot run. It also names the exact return structure, all without contradicting the annotations.

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 compact and front-loaded with the core purpose, then adds cost, billing behavior, and return shape in a logical order. Every sentence earns its place and every sentence is actionable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with a rich output schema, the description covers the necessary context: what audits run, pricing, partial-failure semantics, and the return format. An agent has enough information to select this tool and invoke it correctly without opening schemas or sibling definitions.

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 input schema already fully documents the single required url parameter. The description only restates that the audit uses 'one URL' and does not add new parameter-level semantics, matching the baseline for fully documented schemas.

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 opens with 'Full website audit in one call' and names the four covered audit areas: accessibility, on-page SEO, HTTP security headers, and page speed/page weight. It clearly distinguishes itself from the individual sibling audit tools by explicitly framing this as the all-in-one bundle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states this is 'Cheaper than four separate calls' and describes the failure/billing behavior, which clearly signals when the bundle is preferable to invoking the four siblings individually. It does not explicitly say 'use individual audits when you only need one area,' so it stops short of full exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_performancePage performance auditA

Read-onlyIdempotent

Inspect

Page speed and page weight audit of a web page from one real browser load: total bytes transferred, HTTP request count and DOM node count, measured rather than estimated, with findings when the page is heavy. Page-weight signals, not Core Web Vitals. $0.05 per call. Returns: pass (bool), metrics{}, findings[] with id/severity/detail.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Live, fetchable http(s) URL to audit.

Output Schema

ParametersJSON Schema

Name	Required	Description
`pass`	Yes	Whether every rule in this dimension passed.
`status`	No	Present only on a completed audit.
`metrics`	No
`findings`	No	One entry per rule that did not pass. Empty when the check is clean.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it specifies that the audit is from 'one real browser load', that values are 'measured rather than estimated', and that it returns pass (bool), metrics{}, and findings[] with id/severity/detail. It also discloses the cost per call, which is a behavioral trait not in the annotations. This is strong but not perfect—it doesn't mention rate limits or what happens on a failed load.

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 compact and front-loaded: it opens with the core purpose, then lists the measured signals, then the key exclusion, then cost, then return shape. Every sentence earns its place, and the most decision-relevant information (what it measures, what it doesn't, cost) comes first. No filler or repetition of the title.

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?

The tool has an output schema, so the description doesn't need to fully explain return values, but it still summarizes the return shape (pass, metrics{}, findings[] with id/severity/detail), which is helpful. The description covers the key context: what is measured, how (real browser load), what is excluded (Core Web Vitals), and cost. It doesn't mention failure behavior or rate limits, but for a read-only, idempotent audit tool with an output schema, this is nearly complete.

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 fully documents the single 'url' parameter. The description adds context that the URL must be 'live, fetchable' and that the audit is from a real browser load, which slightly enriches the schema's 'Live, fetchable http(s) URL to audit.' However, the description doesn't add meaning beyond what the schema already provides—the schema already says 'Live, fetchable http(s) URL to audit.' 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 states a specific verb ('audit'), a specific resource ('a web page'), and the exact scope ('page speed and page weight... total bytes transferred, HTTP request count and DOM node count'). It also explicitly distinguishes itself from Core Web Vitals and names the sibling audit tools implicitly by listing the audit family. An agent can tell this apart from audit_bundle, audit_security, audit_seo, and audit_wcag without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states what the tool measures and what it does not measure ('Page-weight signals, not Core Web Vitals'), which helps an agent decide when to use it. It also gives a concrete cost signal ($0.05 per call) that implies a usage consideration. However, it does not explicitly name alternatives or state when not to use it (e.g., 'for Core Web Vitals use X'), so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_securitySecurity header auditA

Read-onlyIdempotent

Inspect

Security headers check for a website: audits HTTPS, HSTS, Content- Security-Policy (CSP), X-Content-Type-Options, X-Frame-Options / clickjacking protection, Referrer-Policy and CORS from the real HTTP response of any live URL. Findings with severity for what is missing. Header posture only, not a penetration test. $0.05 per call. Returns: pass (bool), findings[] with id/severity/detail.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Live, fetchable http(s) URL to audit.

Output Schema

ParametersJSON Schema

Name	Required	Description
`pass`	Yes	Whether every rule in this dimension passed.
`status`	No	Present only on a completed audit.
`findings`	No	One entry per rule that did not pass. Empty when the check is clean.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the agent knows the operation is safe and non-destructive. The description adds context about the pricing ($0.05 per call) and what the tool does not do (penetration test), which is useful. However, it does not disclose potential external network access requirements, rate limits, or that the URL must be publicly accessible, which could be relevant for the agent's decision-making. The description adds some value but not comprehensive behavioral 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 concise and front-loaded: the first sentence states the primary purpose, followed by specific header examplesLOB, an explicit scope limitation, pricing, and a return format summary. Every sentence adds value without redundancy. The structure is logical, moving from what it does to what it doesn't do, to cost and output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema and full parameter schema coverage, the description provides a complete picture for correct invocation. It covers the scope, limitations, cost, and output format, which is sufficient for an agent to decide and call the tool correctly. There are no significant gaps that would prevent correct 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?

The schema defines the 'url' parameter with a description and examples, covering 100% of parameter semantics. The description adds that the URL must be 'live' and 'fetchable', and mentions the HTTP response, but these are partially redundant with the schema's 'live, fetchable http(s) URL' description. With high schema coverage, baseline is 3, and the description provides minimal additional meaning beyond what the schema already conveys.

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 audits security headers of a live URL, enumerating specific headers checked and explicitly distinguishing it from a penetration test. This differentiates it from sibling audit tools (performance, SEO, WCAG) by specifying the domain (security headers) and scope (header posture only). The verb 'audits' with a specific resource (security headers) makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool: for security header checks, not for penetration testing. It clearly states the scope and limitations ('Header posture only, not a penetration test'), which helps an agent decide if this is the right tool for a security audit. However, it does not explicitly mention when not to use it in favor of more comprehensive security tools, but the exclusion of penetration testing provides sufficient guidance for most use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_seoSEO and metadata auditA

Read-onlyIdempotent

Inspect

SEO audit of a web page (on-page SEO check) for any live URL or raw HTML: title tag, meta description, H1 heading structure, canonical link, OpenGraph and social tags, JSON-LD structured data, html lang attribute. Rule-by-rule findings with severity and what is missing or malformed. $0.05 per call. Returns: pass (bool), findings[] with id/severity/detail.

ParametersJSON Schema

Name	Required	Description	Default
`url`	No	Live, fetchable http(s) URL to audit.
`html`	No	Raw HTML source to audit instead of fetching a URL.

Output Schema

ParametersJSON Schema

Name	Required	Description
`pass`	Yes	Whether every rule in this dimension passed.
`status`	No	Present only on a completed audit.
`findings`	No	One entry per rule that did not pass. Empty when the check is clean.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that: it returns rule-by-rule findings with severity, notes missing/malformed elements, and states the per-call cost. No contradiction with annotations was found.

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 compact and front-loaded: it states the purpose first, then lists the audited elements, output behavior, cost, and return shape in one tight block. There is no filler or repetition that would waste an agent's attention.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity, rich annotations, and presence of an output schema, the description is complete for correct invocation. It covers input modes, the audit scope, output structure, and pricing, with no obvious missing details an agent would need.

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 fully documents the url and html parameters. The description's phrase 'live URL or raw HTML' mirrors the schema rather than adding new semantic meaning, keeping this at the baseline score.

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 names a specific action and resource: a 'SEO audit of a web page' for 'any live URL or raw HTML', and enumerates the exact checks (title tag, meta description, H1, canonical, OpenGraph, JSON-LD, lang attribute). This clearly distinguishes audit_seo from its audit_* siblings by domain and scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly establishes the context: use it for on-page SEO/metadata audits of a live URL or raw HTML. It does not explicitly name alternatives or state when not to use it, but the sibling tool names and the SEO-specific title make the selection obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_wcagAccessibility audit (WCAG 2.1 A/AA)A

Read-onlyIdempotent

Inspect

Website accessibility audit (a11y, WCAG compliance check): WCAG 2.1 level A and AA conformance of any live URL or raw HTML, tested with axe-core in a real headless browser. Returns every violation with rule id, impact, help text and affected node count. Deterministic rules; a check that cannot run returns an error, never a pass. $0.05 per call. Returns: pass (bool), violations[] with id/impact/help/help_url/nodes_affected.

ParametersJSON Schema

Name	Required	Description	Default
`url`	No	Live, fetchable http(s) URL to audit.
`html`	No	Raw HTML source to audit instead of fetching a URL.

Output Schema

ParametersJSON Schema

Name	Required	Description
`pass`	Yes	Whether every rule in this dimension passed.
`engine`	No
`status`	No	Present only on a completed audit.
`violations`	No

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only and idempotent annotations, the description adds that rules are deterministic, failures return an error rather than a pass, and it includes the return structure and cost. This provides valuable behavioral context without contradicting annotations.

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 dense paragraph that front-loads the purpose and then covers method, determinism, error behavior, cost, and return shape. Every sentence adds unique information and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description covers input, output, error behavior, cost, and method, which is sufficient for an agent to call it correctly. No missing critical information such as prerequisites or limits.

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 already fully documents both parameters with descriptions, and the description adds little beyond restating 'live URL or raw HTML'. With 100% schema coverage, the description provides no additional parameter semantics beyond what the schema offers.

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 accessibility audits against WCAG 2.1 A/AA, names the method (axe-core in headless browser), and specifies input types (live URL or raw HTML). This distinguishes it from sibling audit tools targeting bundle, performance, security, and SEO.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for accessibility checks but does not explicitly contrast with siblings or state when not to use. The context is clear enough for an agent to infer, but there is no explicit alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesSep 19, 2026
- Removedchain_rpc
- Removedmarket_data
- Removedprediction_markets
- Removedweb_extract
- Removedweb_fetch
5 tool updatesSep 16, 2026
- Addedchain_rpc
- Addedmarket_data
- Addedprediction_markets
- Addedweb_extract
- Addedweb_fetch
2 tool updatesSep 12, 2026
- Changedaudit_bundle2 fields changed
  - changedOutput schema / properties / wcag / properties / violations / items / properties / help / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedOutput schema / properties / wcag / properties / violations / items / properties / impact / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedaudit_wcag2 fields changed
  - changedOutput schema / properties / violations / items / properties / help / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedOutput schema / properties / violations / items / properties / impact / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```

5 tool updatesAug 25, 2026

Changedaudit_bundle6 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / url / description

Previous value: -"Live URL to audit"New value: +"Live, fetchable http(s) URL to audit."

addedInput schema / properties / url / examples
```
Added value: +[
+  "https://example.com"
+]
```
addedInput schema / properties / url / format
```
Added value: +"uri"
```
addedInput schema / title
```
Added value: +"Live URL to audit"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "pass": {
+      "description": "Whether every rule in this dimension passed.",
+      "type": "boolean"
+    },
+    "performance": {
+      "$schema": "https://json-schema.org/draft/2020-12/schema",
+      "properties": {
+        "findings": {
+          "description": "One entry per rule that did not pass. Empty when the check is clean.",
+          "items": {
+            "properties": {
+              "detail": {
+                "description": "What failed and where.",
+                "type": "string"
+              },
+              "id": {
+                "description": "Stable rule identifier.",
+                "type": "string"
+              },
+              "severity": {
+                "description": "Rule severity.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "id"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "metrics": {
+          "properties": {
+            "dom_node_count": {
+              "minimum": 0,
+              "type": "integer"
+            },
+            "request_count": {
+              "minimum": 0,
+              "type": "integer"
+            },
+            "total_bytes_transferred": {
+              "minimum": 0,
+              "type": "integer"
+            }
+          },
+          "type": "object"
+        },
+        "pass": {
+          "description": "Whether every rule in this dimension passed.",
+          "type": "boolean"
+        },
+        "status": {
+          "const": "ok",
+          "description": "Present only on a completed audit.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "pass"
+      ],
+      "type": "object"
+    },
+    "security": {
+      "$schema": "https://json-schema.org/draft/2020-12/schema",
+      "properties": {
+        "findings": {
+          "description": "One entry per rule that did not pass. Empty when the check is clean.",
+          "items": {
+            "properties": {
+              "detail": {
+                "description": "What failed and where.",
+                "type": "string"
+              },
+              "id": {
+                "description": "Stable rule identifier.",
+                "type": "string"
+              },
+              "severity": {
+                "description": "Rule severity.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "id"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "pass": {
+          "description": "Whether every rule in this dimension passed.",
+          "type": "boolean"
+        },
+        "status": {
+          "const": "ok",
+          "description": "Present only on a completed audit.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "pass"
+      ],
+      "type": "object"
+    },
+    "seo": {
+      "$schema": "https://json-schema.org/draft/2020-12/schema",
+      "properties": {
+        "findings": {
+          "description": "One entry per rule that did not pass. Empty when the check is clean.",
+          "items": {
+            "properties": {
+              "detail": {
+                "description": "What failed and where.",
+                "type": "string"
+              },
+              "id": {
+                "description": "Stable rule identifier.",
+                "type": "string"
+              },
+              "severity": {
+                "description": "Rule severity.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "id"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "pass": {
+          "description": "Whether every rule in this dimension passed.",
+          "type": "boolean"
+        },
+        "status": {
+          "const": "ok",
+          "description": "Present only on a completed audit.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "pass"
+      ],
+      "type": "object"
+    },
+    "status": {
+      "const": "ok",
+      "description": "Present only on a completed audit.",
+      "type": "string"
+    },
+    "wcag": {
+      "$schema": "https://json-schema.org/draft/2020-12/schema",
+      "properties": {
+        "engine": {
+          "const": "axe-core",
+          "type": "string"
+        },
+        "pass": {
+          "description": "Whether every rule in this dimension passed.",
+          "type": "boolean"
+        },
+        "status": {
+          "const": "ok",
+          "description": "Present only on a completed audit.",
+          "type": "string"
+        },
+        "violations": {
+          "items": {
+            "properties": {
+              "help": {
+                "type": "string"
+              },
+              "help_url": {
+                "format": "uri",
+                "type": "string"
+              },
+              "id": {
+                "description": "axe-core rule id.",
+                "type": "string"
+              },
+              "impact": {
+                "description": "axe-core impact level.",
+                "type": "string"
+              },
+              "nodes_affected": {
+                "minimum": 0,
+                "type": "integer"
+              }
+            },
+            "required": [
+              "id"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "pass"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "pass"
+  ],
+  "type": "object"
+}

Changedaudit_performance6 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / url / description

Previous value: -"Live URL to audit"New value: +"Live, fetchable http(s) URL to audit."

addedInput schema / properties / url / examples
```
Added value: +[
+  "https://example.com"
+]
```
addedInput schema / properties / url / format
```
Added value: +"uri"
```
addedInput schema / title
```
Added value: +"Live URL to audit"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "findings": {
+      "description": "One entry per rule that did not pass. Empty when the check is clean.",
+      "items": {
+        "properties": {
+          "detail": {
+            "description": "What failed and where.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Stable rule identifier.",
+            "type": "string"
+          },
+          "severity": {
+            "description": "Rule severity.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "metrics": {
+      "properties": {
+        "dom_node_count": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "request_count": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "total_bytes_transferred": {
+          "minimum": 0,
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    },
+    "pass": {
+      "description": "Whether every rule in this dimension passed.",
+      "type": "boolean"
+    },
+    "status": {
+      "const": "ok",
+      "description": "Present only on a completed audit.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "pass"
+  ],
+  "type": "object"
+}

Changedaudit_security6 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / url / description

Previous value: -"Live URL to audit"New value: +"Live, fetchable http(s) URL to audit."

addedInput schema / properties / url / examples
```
Added value: +[
+  "https://example.com"
+]
```
addedInput schema / properties / url / format
```
Added value: +"uri"
```
addedInput schema / title
```
Added value: +"Live URL to audit"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "findings": {
+      "description": "One entry per rule that did not pass. Empty when the check is clean.",
+      "items": {
+        "properties": {
+          "detail": {
+            "description": "What failed and where.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Stable rule identifier.",
+            "type": "string"
+          },
+          "severity": {
+            "description": "Rule severity.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "pass": {
+      "description": "Whether every rule in this dimension passed.",
+      "type": "boolean"
+    },
+    "status": {
+      "const": "ok",
+      "description": "Present only on a completed audit.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "pass"
+  ],
+  "type": "object"
+}

Changedaudit_seo8 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "url"
+    ]
+  },
+  {
+    "required": [
+      "html"
+    ]
+  }
+]

changedInput schema / properties / html / description

Previous value: -"Raw HTML to audit instead of a URL"New value: +"Raw HTML source to audit instead of fetching a URL."

changedInput schema / properties / url / description

Previous value: -"Live URL to audit"New value: +"Live, fetchable http(s) URL to audit."

addedInput schema / properties / url / examples
```
Added value: +[
+  "https://example.com"
+]
```
addedInput schema / properties / url / format
```
Added value: +"uri"
```

addedInput schema / title

Added value: +"Live URL or raw HTML to audit"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "findings": {
+      "description": "One entry per rule that did not pass. Empty when the check is clean.",
+      "items": {
+        "properties": {
+          "detail": {
+            "description": "What failed and where.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Stable rule identifier.",
+            "type": "string"
+          },
+          "severity": {
+            "description": "Rule severity.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "pass": {
+      "description": "Whether every rule in this dimension passed.",
+      "type": "boolean"
+    },
+    "status": {
+      "const": "ok",
+      "description": "Present only on a completed audit.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "pass"
+  ],
+  "type": "object"
+}

Changedaudit_wcag8 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "url"
+    ]
+  },
+  {
+    "required": [
+      "html"
+    ]
+  }
+]

changedInput schema / properties / html / description

Previous value: -"Raw HTML to audit instead of a URL"New value: +"Raw HTML source to audit instead of fetching a URL."

changedInput schema / properties / url / description

Previous value: -"Live URL to audit"New value: +"Live, fetchable http(s) URL to audit."

addedInput schema / properties / url / examples
```
Added value: +[
+  "https://example.com"
+]
```
addedInput schema / properties / url / format
```
Added value: +"uri"
```

addedInput schema / title

Added value: +"Live URL or raw HTML to audit"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "engine": {
+      "const": "axe-core",
+      "type": "string"
+    },
+    "pass": {
+      "description": "Whether every rule in this dimension passed.",
+      "type": "boolean"
+    },
+    "status": {
+      "const": "ok",
+      "description": "Present only on a completed audit.",
+      "type": "string"
+    },
+    "violations": {
+      "items": {
+        "properties": {
+          "help": {
+            "type": "string"
+          },
+          "help_url": {
+            "format": "uri",
+            "type": "string"
+          },
+          "id": {
+            "description": "axe-core rule id.",
+            "type": "string"
+          },
+          "impact": {
+            "description": "axe-core impact level.",
+            "type": "string"
+          },
+          "nodes_affected": {
+            "minimum": 0,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "id"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "pass"
+  ],
+  "type": "object"
+}

5 tool updatesAug 11, 2026
- First observedaudit_bundle
- First observedaudit_performance
- First observedaudit_security
- First observedaudit_seo
- First observedaudit_wcag

Related MCP Connectors

Web Validator by DigestSEO A
io.github.AKzar1el
Audit public webpages and supplied markup for HTML, CSS, SEO, JSON-LD, and link issues.
Marketing Testing & QA Tools Browser Automation
817
dropcoin-a11y A
io.github.freshfos
Accessibility pre-checks (WCAG/BFSG) in a real browser + statement drafts. Pay per call.
Testing & QA Tools Browser Automation
21
PageLens AIOAuth
io.github.PageLens-AI
AI website audit: security, SEO, performance, UX and accessibility checks with actionable fixes.
Monitoring Search
2
agentready A
io.github.msanchezgrice
Scan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
Security Web Scraping Penetration Testing
72

Related MCP Servers

web-audit-mcp
Browser Automation Web Scraping Monitoring
sayuru-akash
F
license
Not graded
quality
D
maintenance
Enables auditing of websites for performance, SEO, accessibility, security, and mobile readiness, with tools to validate URLs, run page audits, save results, and retrieve reports.
Updated 4 months ago (2026-05-08 01:28 UTC)
1
-
sitehealth-mcp
Monitoring Web Scraping
carsonroell-debug
A
license
A
quality
D
maintenance
Performs comprehensive website health audits including SSL, DNS, email authentication, performance, uptime, and broken link checks, all without requiring API keys. Returns a scored report with weighted metrics and actionable recommendations.
Updated 5 months ago (2026-04-27 19:21 UTC)
7
66 npm
MIT
SyteCheck MCP Server
Browser Automation Monitoring Web Scraping
BertPC
A
license
A
quality
B
maintenance
Enables running comprehensive website audits from any MCP client, returning actionable plain-language reports covering SEO, accessibility, performance, security, and more.
Updated 11 days ago (2026-09-10 15:06 UTC)
6
354 npm
MIT
website-audit
Testing & QA Tools
rolledoatmeals
A
license
A
quality
B
maintenance
Enables auditing any public website, returning a scored plain-English report that flags issues costing customers, covering speed, phone experience, search visibility, contact options, writing quality, and modernity.
Updated a month ago (2026-08-25 12:28 UTC)
1
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources