Skip to main content
Glama
Sign In
fairquery-web

fairquery-web

Official
by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Compare two SEO audits: before/after or site vs site (free)

web_compare_snapshots
Read-onlyIdempotent

Compare two SEO and AI-readiness snapshots to spot score changes, new or resolved issues, and field updates—ideal for tracking regressions, verifying fixes, or checking competitors.

Instructions

Diff two SEO/AI-readiness snapshots field by field: score deltas, issues added/resolved, and changes to title, meta description, canonical, H1s, JSON-LD types, Open Graph, technologies, AI-bot access, llms.txt, sitemap, status and more. Three modes: (1) before + after = two snapshot objects you saved earlier from web_seo_audit (or site rows from web_batch_audit) - no fetching; (2) before + url = historical follow-up: re-audits url now and compares with the saved snapshot; (3) url + compareUrl = audits two live URLs (e.g. competitor vs own site, staging vs production). WHEN TO USE: track SEO regressions/improvements over time, verify a fix, compare competitors. Fetches like web_seo_audit (live modes only). RETURNS: {summary{before_url, after_url, before_checked_at, after_checked_at, seo_score_before, seo_score_after, seo_score_delta, ai_readiness_score_delta, issues_added, issues_resolved, changed_fields}, changes[{type:"change", field, before, after, delta?, added?, removed?} | {type:"issue_added"|"issue_resolved", code}], before, after (only fetched snapshots are echoed)}. Errors: INVALID_ARGUMENTS (wrong mode combination) plus INVALID_URL, BLOCKED_PRIVATE_ADDRESS, DNS_FAILED, FETCH_FAILED, TIMEOUT, TOO_MANY_REDIRECTS. WHEN NOT TO USE: for a single audit without comparison use web_seo_audit. COST: free (local fetches, no APIFY_TOKEN). PARAMETERS: exactly one of three combinations is accepted, any other combination (including all four or a single field) returns INVALID_ARGUMENTS without fetching: {before, after} | {before, url} | {url, compareUrl}. before/after must be whole snapshot objects as returned (type "seo_audit" from web_seo_audit, or a "site" row from web_batch_audit) - pass them unmodified; missing fields are compared as null. In {before, url} the live side is re-audited with checkRobots=true, so compare it only with a snapshot also taken with checkRobots=true. In {url, compareUrl} url is the "before" side and compareUrl the "after" side, so seo_score_delta = compareUrl score minus url score. url and compareUrl follow the same rules as web_seo_audit url (bare domain -> https, exact page). EXAMPLE: {"url":"mysite.com","compareUrl":"competitor.com"} -> {summary:{seo_score_delta, issues_added, ...}, changes:[...]}

Input Schema

NameRequiredDescriptionDefault
urlNoOptional; used with before or compareUrl. Public domain or http(s) URL audited live: the "after" side (with before) or the "before" side (with compareUrl). Example: "mysite.com"
afterNoOptional; used only with before. Later snapshot object of the same shape to compare against before
beforeNoOptional; used with after or url. Earlier snapshot object, unmodified output of web_seo_audit (type "seo_audit") or a web_batch_audit "site" row. Example: {"type":"seo_audit","final_url":"https://example.com/","seo_score":72,...}
compareUrlNoOptional; used only with url. Second public domain or http(s) URL audited live as the "after" side. Example: "competitor.com"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.2.4
    • changedInput schema / properties / after / description
      Previous value: -"Later snapshot object to compare against before"New value: +"Optional; used only with before. Later snapshot object of the same shape to compare against before"
    • changedInput schema / properties / before / description
      Previous value: -"Earlier snapshot object (output of web_seo_audit or a web_batch_audit site row)"New value: +"Optional; used with after or url. Earlier snapshot object, unmodified output of web_seo_audit (type \"seo_audit\") or a web_batch_audit \"site\" row. Example: {\"type\":\"seo_audit\",\"final_url\":\"https://example.com/\",\"seo_score\":72,...}"
    • changedInput schema / properties / compareUrl / description
      Previous value: -"Second live URL to audit and compare against url"New value: +"Optional; used only with url. Second public domain or http(s) URL audited live as the \"after\" side. Example: \"competitor.com\""
    • changedInput schema / properties / url / description
      Previous value: -"URL to audit live: the \"after\" side (with before) or the first side (with compareUrl)"New value: +"Optional; used with before or compareUrl. Public domain or http(s) URL audited live: the \"after\" side (with before) or the \"before\" side (with compareUrl). Example: \"mysite.com\""
  2. Addedv1.2.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond that: exactly one of three argument combinations is accepted or INVALID_ARGUMENTS is returned without fetching, live modes fetch like web_seo_audit, the live side uses checkRobots=true, snapshots must be passed unmodified, missing fields compare as null, and the tool is free with no APIFY_TOKEN.

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?

Front-loaded with the core diff and the three modes, then cleanly sectioned into WHEN TO USE / RETURNS / WHEN NOT / COST / PARAMETERS / EXAMPLE. It is long, and the EXAMPLE plus the mode list duplicate some of the PARAMETERS bullets, but every section carries usable routing or invocation detail.

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?

No output schema exists, yet the description spells out the full return shape (summary deltas, changes array with change/issue_added/issue_resolved entries, echoed snapshots) and enumerates the error codes. For a zero-required-parameter, multi-mode tool this is complete enough to invoke correctly without guessing.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, and the description earns extra credit by explaining combination validity, that before/after must be whole unmodified snapshots (with null for missing fields), and the delta direction in url+compareUrl mode (compareUrl minus url). The one gap is that the PARAMETERS prose partly restates the schema rather than adding new distinctions for each field.

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?

States a specific verb (diff) over a specific resource (SEO/AI-readiness snapshots) and enumerates the exact fields compared. It also distinguishes itself from web_seo_audit by framing this as comparison rather than single audit work.

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?

Provides explicit WHEN TO USE (track regressions, verify a fix, compare competitors), three concrete modes with which arguments select each, and an explicit WHEN NOT TO USE naming web_seo_audit for single audits. Nothing is left to inference.

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

Deploy Server

Other Tools