Loading ToolBench
W3C HTML/CSS Validator and Technical SEO Audit MCP Server for AI coding assistants.
Mixed quality across 11 tools. Strengths: all tools have non-empty descriptions (10-160 chars typical); all input schemas are visible with proper type declarations; tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) are applied correctly; structured output schemas defined via Zod. Weaknesses: many parameter descriptions are minimal (single phrase, <20 chars); output schemas documented via Zod but not reflected in tool registration itself; error handling relies on generic failure patterns without actionable recovery guidance; some tool names could be more specific (e.g., 'audit_site' is vague about scope/limits); composition issues with tools like 'generate_validation_report' and 'audit_site' that combine multiple concerns. No parameters expose secrets, security is sound.
Audits on-page SEO metadata and accessibility signals without fetching or storing any external content.
Performs a comprehensive technical SEO audit of a website by crawling multiple pages and validating HTML, CSS, SEO, and schema markup.
Captures screenshots of a web page at multiple viewport sizes for visual validation.
Checks for broken or invalid links in HTML content.
Fetches and validates HTML content from a public URL with security checks and redirect validation.
Generates a comprehensive validation report combining HTML, CSS, SEO, schema, and link validation checks.
Validates CSS markup text directly against W3C CSS standards without reading from a file.
Parameter descriptions are extremely brief and lack context for LLM selection. Example: 'filePath' on validate_html_file is just 'Path to the HTML file to validate' (38 chars). Baseline for A+ tools is 72 chars avg. Should include format hints, constraints, and dependency guidance like 'Relative or absolute path (max 4096 chars). Returns validation errors if file does not exist or is unreadable.'
Tool names 'audit_seo_metadata' and 'audit_site' are vague about scope. 'audit_seo_metadata' does not clarify it takes HTML content, not a URL. 'audit_site' does not indicate it crawls multiple pages (max 8) or that it's read-only. Naming should be more specific: 'audit_html_seo_metadata' and 'crawl_and_audit_site' would better signal intent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2025-06-18+ | v2 |
Validates CSS content from a local file against W3C CSS standards.
Validates HTML markup text directly against W3C HTML standards without reading from a file.
Validates HTML content from a local file against W3C HTML standards.
Validates JSON-LD schema markup syntax and structure.
Output schemas are defined internally via Zod but not exposed in tool registration. LLMs cannot see what fields to expect in responses. Tool descriptions mention 'comprehensive validation report' and 'multiple viewport configurations' but never specify the response structure (e.g., htmlScore, cssScore, linkScore, screenshots array). Responses should be documented as structured objects with field descriptions.
Error handling is generic and does not guide recovery. Failures return isError=true with text message but no actionable next steps. Example: if fetch_public_html hits a 404, the error should suggest 'URL not found. Verify the URL is correct and publicly accessible. Try check_broken_links to validate related links.' Current code returns only the HTTP error without recovery guidance.
Composition issue: 'generate_validation_report' and 'audit_site' combine HTML validation, CSS validation, SEO audit, schema validation, and link checking into single tools. This violates the single-responsibility principle. Users cannot validate HTML without also validating CSS. Agents should compose these independently: validate_html_file + validate_css_file + audit_seo_metadata + validate_schema_markup + check_broken_links.
'viewports' parameter on capture_screenshots has no description of format. Should specify: 'Array of viewport objects, each with required properties width (px, 320 - 1920) and height (px, 480 - 1080). Max 8 viewports. Example: [{"width": 1920, "height": 1080}, {"width": 768, "height": 1024}]'
'maxPages' parameter on audit_site has default of 5 with max of 8, but the description does not make it clear whether omitting this param is safe or if the LLM must reason about crawl depth. Add: 'Defaults to 5. Omit to use default. Set higher for broader site coverage but longer execution time.'
Tools returning lists (e.g., validate_html_file returns htmlMessages array, audit_site crawls pages) do not document total count or pagination. If htmlMessages has 100+ entries, there is no way to fetch the rest or know the total. Add limit/offset parameters and total count in response.
Parameter 'allowedOrigin' on fetch_public_html lacks description of format. Should specify: 'Optional domain whitelist to prevent redirect attacks. Example: https://example.com (protocol and domain only, no path or trailing slash). If omitted, redirects to any HTTPS origin are allowed.'
Tool annotations are applied globally to all tools as either externalReadOnlyAnnotations or localReadOnlyAnnotations, but this assumes all tools have identical behavior. In reality, capture_screenshots and audit_site contact external services (openWorldHint=true), while validate_html_content does not (openWorldHint=false). Annotations are correctly differentiated in code, but dynamically applied per-tool at registration time, which is good. However, tool descriptions do not mention these constraints, making it unclear to LLMs which tools have external side effects.