Website Auditor MCP

What changed in AI visibility

get_changes

Read-only

See how a website's AI-visibility score changed between two matching snapshots, showing per-engine differences.

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." Requires the domain to be tracked (see track_site). Returns the change in the overall score and the per-engine score changes, for engines measured both times; 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 ($10/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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`since`	No	Optional ISO date or "last_check".
`domain`	Yes	The website domain, e.g. "example.com".

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	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_issues`	Yes	Always empty: AI-visibility snapshots record no audit issues. Kept for clients that read it.
`score_delta`	Yes	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.
`engine_changes`	Yes
`to_captured_at`	No	When the later one was.
`resolved_issues`	Yes	Always empty: AI-visibility snapshots record no audit issues. Kept for clients that read it.
`from_captured_at`	No	When the earlier snapshot compared was captured.
`skipped_snapshots`	No	Snapshots passed over because they asked a different question (another business name, market or queries) or do not record what they asked.
`competitor_changes`	Yes	Always empty: AI-visibility snapshots record no competitors. Kept for clients that read it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv1.0.24Sep 17, 2026

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"
+}

Changed1 schema field changedv1.0.23Sep 9, 2026

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"
+}

First observedv1.0.6Jul 29, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only convey read-only and non-destructive hints. The description adds substantial behavioral context: changes are only measured between same-question snapshot pairs, competitor_changes/new_issues/resolved_issues are always empty, no-pair cases explain why and report re-baseline dates, and the series definition is spelled out. No contradiction with annotations.

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?

The description is a dense, single-paragraph wall of text with extremely long, convoluted sentences, especially the series-definition clause. Although the first sentence is front-loaded, the subscription/trial details and nested conditional logic make it hard to scan and substantially exceed what is needed for a 2-parameter tool.

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?

Given an output schema exists, the description still explains return semantics (overall and per-engine score changes, always-empty fields), error behavior when no valid snapshot pair exists, subscription requirements, and the fallback to get_sample_audit. An agent has everything needed to invoke and interpret this tool correctly.

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 description coverage is 100%, so both domain and since are already documented in the schema. The description reinforces that the domain must be tracked and that 'since' relates to snapshot pairing, but it adds no new syntax or format details beyond what the schema provides.

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 opening sentence states a specific verb and resource: 'Report what changed in a website's AI-visibility score, only between two snapshots that asked the same question.' This clearly distinguishes the tool from siblings like get_ai_visibility (current value) and compare_competitors (competitor comparisons).

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?

The description explicitly says when to use it ('Use this when someone asks...') with concrete example queries, and names preconditions and alternatives: domain must be tracked (see track_site) and non-subscribers should call get_sample_audit first. This gives an agent clear selection and fallback logic.

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

Deploy Server