Skip to main content
Glama
fairquery-web

fairquery-web

Official

Single-page SEO & AI-readiness audit with 0-100 score (free)

web_seo_audit
Read-onlyIdempotent

Audit one URL for on-page SEO issues, scores, AI readiness, robots.txt, sitemap, and structured data, then return a snapshot for before/after comparison.

Instructions

Full on-page audit of ONE URL: title, meta description, canonical, lang, meta robots, viewport, H1s, heading/word/link/image counts, images missing alt, Open Graph, Twitter card, JSON-LD @types, hreflang, feeds, social links, detected technologies, robots.txt/sitemap/llms.txt presence and AI-bot access, plus seo_score (0-100, deductions: high 15 / medium 8 / low 3) with seo_issues[{code, severity, message}] and ai_readiness_score (0-100). Issue codes: NO_HTTPS, MISSING_TITLE, TITLE_TOO_LONG, TITLE_TOO_SHORT, MISSING_META_DESCRIPTION, META_DESCRIPTION_TOO_LONG, MISSING_H1, MULTIPLE_H1, MISSING_CANONICAL, MISSING_LANG, MISSING_VIEWPORT, NOINDEX, MISSING_OPEN_GRAPH, MISSING_STRUCTURED_DATA, IMAGES_MISSING_ALT, THIN_CONTENT, MISSING_ROBOTS_TXT, MISSING_SITEMAP. WHEN TO USE: SEO health of a specific page, or to create a snapshot you can store and later pass to web_compare_snapshots for before/after tracking. For just one aspect use web_ai_crawler_access, web_tech_stack, web_sitemap_info or web_security_headers; for many sites use web_batch_audit. Fetching: GETs from this server with User-Agent "FairqueryBot ... Fairquery-MCP", 15 s timeout per request, body capped (1.5 MB HTML), max 5 redirects, no JavaScript rendering; URLs resolving to private/loopback/link-local addresses are refused (SSRF guard). Makes ~5 requests (page, robots.txt, sitemap, llms.txt, llms-full.txt) unless checkRobots=false. RETURNS: one "seo_audit" snapshot object (snapshot_schema "fairquery-web-snapshot/1") with the fields above plus input, final_url, status_code, https, response_ms, html_truncated, checked_at. Errors (isError=true, JSON {error, message, retryable}): INVALID_URL, BLOCKED_PRIVATE_ADDRESS, DNS_FAILED, FETCH_FAILED, TIMEOUT, TOO_MANY_REDIRECTS. WHEN NOT TO USE: only need reachability (web_quick_check), only AI-bot rules (web_ai_crawler_access), only stack (web_tech_stack), or many sites (web_batch_audit, paid). COST: free - runs locally in this MCP server (direct HTTP GETs), no APIFY_TOKEN, no Apify billing. PARAMETERS: url: the exact page is audited (path and query matter: "python.org" audits the homepage, "python.org/about/" that page), after following up to 5 redirects; on-page fields describe the final_url, while robots.txt, sitemap and llms.txt are always taken from the final URL's origin. Pass "http://..." explicitly to get the NO_HTTPS check on a site that does not redirect. checkRobots=false fetches only the page (1 request instead of ~5): robots_txt_found, sitemap_found, llms_txt_found and ai_bots become null, MISSING_ROBOTS_TXT / MISSING_SITEMAP are never raised and ai_readiness_score is computed from page signals only - so seo_score can be higher and the snapshot is not comparable with a checkRobots=true one in web_compare_snapshots. Keep the default true for snapshots you intend to compare later. EXAMPLE: {"url":"python.org/about/"} -> {type:"seo_audit", seo_score:0-100, ai_readiness_score:0-100, seo_issues:[{code, severity, message}], ...}

Input Schema

NameRequiredDescriptionDefault
urlYesRequired. One public domain or http(s) URL (non-empty string), e.g. "vercel.com" or "https://www.python.org/about/". Bare domains are fetched over https; other schemes, credentials in the URL, dot-less hosts and private/loopback addresses are refused.
checkRobotsNoOptional boolean, default true. true also fetches robots.txt, the XML sitemap, /llms.txt and /llms-full.txt from the page origin (~5 requests); false = page only (1 request, faster; robots/sitemap/llms fields null and their issues skipped). Example: false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.4
    • changedInput schema / properties / checkRobots / description
      Previous value: -"Also fetch robots.txt, sitemap and llms.txt for AI-bot/sitemap checks and scores (default true). false = page only, faster."New value: +"Optional boolean, default true. true also fetches robots.txt, the XML sitemap, /llms.txt and /llms-full.txt from the page origin (~5 requests); false = page only (1 request, faster; robots/sitemap/llms fields null and their issues skipped). Example: false"
    • changedInput schema / properties / url / description
      Previous value: -"Required. One public domain or http(s) URL, e.g. \"vercel.com\" or \"https://www.python.org/about/\". Bare domains are fetched over https; private/loopback hosts are refused."New value: +"Required. One public domain or http(s) URL (non-empty string), e.g. \"vercel.com\" or \"https://www.python.org/about/\". Bare domains are fetched over https; other schemes, credentials in the URL, dot-less hosts and private/loopback addresses are refused."
  2. Addedv1.2.1

TDQS

A5/5.0
Behavior5/5

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

Annotations only declare the generic safety profile (readOnly, idempotent, openWorld, non-destructive); the description adds concrete operational behavior far beyond them: GET with a named User-Agent, 15s timeout, 1.5 MB body cap, max 5 redirects, no JS rendering, SSRF refusal of private/loopback addresses, ~5 outbound requests, and the free/local cost model. It also enumerates the error codes and the isError JSON shape.

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?

Though long, it is tightly sectioned (purpose, issue codes, WHEN TO USE, fetching, RETURNS, WHEN NOT TO USE, COST, PARAMETERS, EXAMPLE) and front-loads the core purpose. The 18 issue codes are the only place those outputs are documented since no output schema exists, so every line earns its place.

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 no output schema, the description carries the full burden and does so: it names the return object ('seo_audit' snapshot, snapshot_schema fairquery-web-snapshot/1), its fields, both scores and their deduction weights, and the error taxonomy. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), but the description materially exceeds the schema: it explains that path/query select the exact page, that on-page fields describe the redirect-resolved final_url while robots/sitemap/llms come from that origin, and that checkRobots=false nulls those fields, suppresses MISSING_ROBOTS_TXT/MISSING_SITEMAP, and makes the snapshot incomparable in web_compare_snapshots.

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 a specific verb+resource ('Full on-page audit of ONE URL') and enumerates the exact fields audited, then names each sibling it is not ('For just one aspect use web_ai_crawler_access, web_tech_stack...; for many sites use web_batch_audit'). An agent can select it correctly without opening any schema.

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

Usage Guidelines5/5

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

Explicit WHEN TO USE and WHEN NOT TO USE sections name the alternatives (web_quick_check, web_ai_crawler_access, web_tech_stack, web_sitemap_info, web_security_headers, web_batch_audit) and the exact condition that selects each. It also explains the snapshot/web_compare_snapshots use case, leaving nothing to inference.

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