Skip to main content
Glama
Website Auditor MCP

Website Auditor MCP

What changed in AI visibility

get_changes
Read-only

Compare a website's AI-visibility scores between two snapshots that asked the same question to show overall and per-engine changes, or explain why no comparable change exists.

Instructions

Report what changed in a website's AI-visibility score, only between two snapshots that asked the same question. Use this when someone asks "did anything change," "what's different this week/month," or "did my AI visibility drop." The domain need not be tracked: history accrues from any audit of it, tracked or not — track_site adds the weekly re-audits to the series, it is not a precondition, so do not track a site just to answer a change question. Returns the change in the overall score and the per-engine score changes, for engines measured both times — the overall only when the same engines answered both snapshots, otherwise it is null with an overall_note naming which answered each, and the per-engine changes stand alone; a summary says the change in plain sentences; competitor_changes, new_issues and resolved_issues are always empty, since snapshots record neither competitors nor audit issues. A change is only ever measured between two snapshots that asked the same question (the same business name, market and queries); when there is no such pair it says why instead of giving a number, with the date the series re-baselined when it did. The series is the measured weekly re-audits and any audit that asked the same question as the newest recorded one, while it has no gap longer than four weeks and a day from the newest weekly re-audit that recorded its question, through each later snapshot of the series (weekly re-audits included, recorded or not), to the newest measured snapshot; otherwise every measured snapshot. Requires a Website Auditor subscription ($49/month; eligible new customers get a 7-day free trial — payment method required, no charge until the trial ends) — if the user doesn't have one, call get_sample_audit first to show them the exact output format, free and with no API key.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "get_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
sinceNoOptional ISO date or "last_check".
domainYesThe website domain, e.g. "example.com".

Output Schema

NameRequiredDescriptionDefault
noteNoPresent when skipped_snapshots is above 0, when the two snapshots compared were answered by different engines, when newer measured snapshots were left out of the series, or when newer weekly re-audits measured nothing of the business: which, and why, in words. Relay it.
summaryNoThe change in plain sentences, built from this result's two snapshots and any newer run the comparison leaves out: the overall scores and move, each assistant that moved, those newer runs, and what Pro checks each week; note beside it carries any snapshot passed over in between.
new_issuesYesAlways empty: AI-visibility snapshots record no audit issues. Kept for clients that read it.
score_deltaYesOnly ever between two snapshots that asked the same question AND were answered by the same engines. When there is no such pair, including a re-baseline after the business name, market or queries changed, the tool returns NOT_YET_AVAILABLE saying so, never a number; when the pair exists but different engines answered the two snapshots, the overall is not subtracted and is null with overall_note, and engine_changes still compares every engine that answered both.
overall_noteNoPresent exactly when score_delta is null: the two snapshots were answered by different engines, and which answered each. Relay it — a null delta for this reason must not read like a null for want of history.
engine_changesYes
to_captured_atNoWhen the later one was.
resolved_issuesYesAlways empty: AI-visibility snapshots record no audit issues. Kept for clients that read it.
from_captured_atNoWhen the earlier snapshot compared was captured.
skipped_snapshotsNoSnapshots passed over because they asked a different question (another business name, market or queries) or do not record what they asked.
competitor_changesYesAlways empty: AI-visibility snapshots record no competitors. Kept for clients that read it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.29
    • addedOutput schema / properties / summary
      Added value: +{
      +  "description": "The change in plain sentences, built from this result's two snapshots and any newer run the comparison leaves out: the overall scores and move, each assistant that moved, those newer runs, and what Pro checks each week; note beside it carries any snapshot passed over in between.",
      +  "type": "string"
      +}
  2. Changed4 schema fields changedv1.0.25
    • changedOutput schema / properties / note / description
      Previous value: -"Present when skipped_snapshots is above 0, when newer measured snapshots were left out of the series, or when newer weekly re-audits measured nothing of the business: which, and why, in words. Relay it."New value: +"Present when skipped_snapshots is above 0, when the two snapshots compared were answered by different engines, when newer measured snapshots were left out of the series, or when newer weekly re-audits measured nothing of the business: which, and why, in words. Relay it."
    • addedOutput schema / properties / overall_note
      Added value: +{
      +  "description": "Present exactly when score_delta is null: the two snapshots were answered by different engines, and which answered each. Relay it — a null delta for this reason must not read like a null for want of history.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / score_delta / description
      Previous value: -"Only ever between two snapshots that asked the same question. When there is no such pair, including a re-baseline after the business name, market or queries changed, the tool returns NOT_YET_AVAILABLE saying so, never a number."New value: +"Only ever between two snapshots that asked the same question AND were answered by the same engines. When there is no such pair, including a re-baseline after the business name, market or queries changed, the tool returns NOT_YET_AVAILABLE saying so, never a number; when the pair exists but different engines answered the two snapshots, the overall is not subtracted and is null with overall_note, and engine_changes still compares every engine that answered both."
    • changedOutput schema / properties / score_delta / type
      Previous value: -"number"New value: +[
      +  "number",
      +  "null"
      +]
  3. Changed8 schema fields changedv1.0.24
    • addedOutput schema / properties / competitor_changes / description
      Added value: +"Always empty: AI-visibility snapshots record no competitors. Kept for clients that read it."
    • addedOutput schema / properties / from_captured_at
      Added value: +{
      +  "description": "When the earlier snapshot compared was captured.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / new_issues / description
      Added value: +"Always empty: AI-visibility snapshots record no audit issues. Kept for clients that read it."
    • addedOutput schema / properties / note
      Added value: +{
      +  "description": "Present when skipped_snapshots is above 0, when newer measured snapshots were left out of the series, or when newer weekly re-audits measured nothing of the business: which, and why, in words. Relay it.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / resolved_issues / description
      Added value: +"Always empty: AI-visibility snapshots record no audit issues. Kept for clients that read it."
    • addedOutput schema / properties / score_delta / description
      Added value: +"Only ever between two snapshots that asked the same question. When there is no such pair, including a re-baseline after the business name, market or queries changed, the tool returns NOT_YET_AVAILABLE saying so, never a number."
    • addedOutput schema / properties / skipped_snapshots
      Added value: +{
      +  "description": "Snapshots passed over because they asked a different question (another business name, market or queries) or do not record what they asked.",
      +  "type": "number"
      +}
    • addedOutput schema / properties / to_captured_at
      Added value: +{
      +  "description": "When the later one was.",
      +  "type": "string"
      +}
  4. Changed1 schema field changedv1.0.23
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "competitor_changes": {
      +      "items": {},
      +      "type": "array"
      +    },
      +    "engine_changes": {
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "delta": {
      +            "type": "number"
      +          },
      +          "engine": {
      +            "type": "string"
      +          },
      +          "from": {
      +            "type": "number"
      +          },
      +          "to": {
      +            "type": "number"
      +          }
      +        },
      +        "required": [
      +          "engine",
      +          "from",
      +          "to",
      +          "delta"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "new_issues": {
      +      "items": {},
      +      "type": "array"
      +    },
      +    "resolved_issues": {
      +      "items": {},
      +      "type": "array"
      +    },
      +    "score_delta": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "score_delta",
      +    "engine_changes",
      +    "competitor_changes",
      +    "new_issues",
      +    "resolved_issues"
      +  ],
      +  "type": "object"
      +}
  5. First observedv1.0.6

TDQS

A4.2/5.0
Behavior4/5

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

Goes well past the readOnly/destructive annotations: it discloses that overall becomes null with an overall_note when engine sets differ, that competitor_changes/new_issues/resolved_issues are always empty, and how re-baselining is reported. The paywall prerequisite ($49/month, 7-day trial, payment method required) is disclosed up front — a material behavioral fact not captured anywhere in structured fields. The definition of the 'series' window is present but phrased in dense nested clauses that are hard to operationalize.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, triggers, output behavior and the fallback path are front-loaded, which is good, but the single sentence defining the series ('while it has no gap longer than four weeks and a day from the newest weekly re-audit that recorded its question, through each later snapshot...') is close to unparseable. Pricing and trial mechanics are also embedded mid-paragraph, inflating length without helping the agent decide or call correctly.

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 two-parameter read tool with full schema coverage, annotations and an output schema, this is more than sufficient. Edge cases an agent would otherwise mishandle — no comparable snapshot pair, changed engine set, always-empty fields, and the subscription gate — are all addressed.

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 coverage is 100%, so the schema already documents both parameters, and the baseline is 3. The description elaborates on time-window semantics through the series definition, which hints at what `since` selects from, but it never explicitly explains what `since` does or how "last_check" versus an ISO date changes behavior — the one parameter ambiguity is left unresolved.

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 and resource: report what changed in a website's AI-visibility score, restricted to comparable snapshots. This distinguishes it from get_ai_visibility (current score) and get_report (full report) without requiring the agent to open 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?

Names concrete trigger questions ("did anything change," "what's different this week/month," "did my AI visibility drop"). It also pre-empts the obvious wrong move by stating the domain need not be tracked and that track_site is not a precondition, and routes users without a subscription to get_sample_audit instead.

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