Loading ToolBench
MCP server for site-spec: audit any website's invisible foundation (SEO, accessibility, privacy, structured data, AI searchability) and auto-fix what's broken, from inside your agent.
Four well-named tools with strong descriptions (avg 180 chars) and complete input schemas. All parameters are typed and described. Output schemas are documented in descriptions. Tool names follow verb_noun pattern (audit_site, fix_issue, compile_spec, list_checks). Risk annotations present. Main gaps: no explicit error handling guidance in descriptions, no pagination for audit_site results, and compile_spec accepts a complex nested object without field-level validation hints.
Audit a website: takes url (a live URL, a bare hostname, or a local directory of built output), optional checks (check ids to filter to) and optional maxPages (1-200, default 25), and returns { ok, target, mode, live, errors, warnings, pages, findings } where every finding carries checkId, severity, file, category and fixAvailable. Covers the layer a browser does not show: robots.txt and llms.txt policy, canonical and noindex signals, structured data, Open Graph, security and cache headers, accessibility semantics, and the tracker/cookie surface.
Compile business data into a deployable site: takes business (the pure-data site config { pack, brief, site, spec }, plus optional foundation and target) and optional out_dir, and returns { ok, pack, spec, files, findings }, with written and writtenTo when out_dir is given. `pack` is a registered pack id, `brief` is the verified business facts (name, category, phone, address, hours, reviews), `site` is deploy context (baseUrl, locales), and `spec` is the page structure; the files rendered are HTML, sitemap.xml, robots.txt, llms.txt, headers and icons. Validation runs at both the spec tier and the rendered tier, so an invalid site never produces output.
Fix one audit finding: takes url_or_path, a single check_id, optional write (default false), optional out_dir and optional maxPages, and returns { checkId, fixAvailable, matchedFindings, actions, diffs, written }. Defaults to a dry run that writes nothing; write: true requires a local directory target and is refused for a URL, because a remote server is not writable. Not every check is repairable: list_checks marks which ones are, and unrepairable findings come back with the manual step spelled out.
compile_spec accepts a complex nested 'business' object without documenting required vs optional fields or validation rules. LLMs cannot infer the structure of { pack, brief, site, spec, foundation?, target? }.
No error recovery guidance in tool descriptions. When audit_site or fix_issue fails, the description does not tell the LLM what to do next (e.g., 'If the URL is unreachable, try a local directory instead').
audit_site returns potentially large result sets (up to 200 pages) with no pagination or result limiting guidance. Description mentions maxPages but does not explain how to handle large finding lists or recommend a default cap.
fix_issue description does not clarify which checks are repairable vs manual-only. It says 'unrepairable findings come back with the manual step spelled out' but does not explain how the LLM should interpret or act on that response.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
List every audit check: takes no arguments and returns { count, fixable, checks } where each check has id, description, category (seo, privacy, security, accessibility, performance, structured-data, ai-searchability, structure) and fixable. Call this before filtering audit_site or calling fix_issue.
compile_spec 'target' parameter is undocumented. Description mentions 'target: "cloudflare"' as an example but does not list valid values or explain what it controls.