Website Auditor MCP

Check a fix is live

check_fix

Verify whether a website fix is live by reading the site for a fix request ID and recording the result: live, or each missing element.

Instructions

"I've added it": check whether a fix is live on the site. Use this when the owner says they have added, pasted or published a fix, or asks "is it live" or "did it work." Reads the live site for the fix request id (from get_fix, or a fix's newest request in list_fixes) and records what it found: live, or what is missing, each named. For the business-facts fix the home page's structured data has to state every fact the fix stated; for llms.txt, /llms.txt has to answer with a valid file; for the robots.txt lines, /robots.txt has to let in every assistant the fix named. A site that did not answer is not called missing the fix (reached false). One check a minute per request: asked again sooner it answers CHECKED_RECENTLY with retry_after. It does not predict any change in AI visibility; the weekly check observes that. 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.

Input Schema

Name	Required	Description	Default
`id`	Yes	The fix request's id: `request.id` from the fix as served, or a fix's newest `request.id` in the site's fix list.
`domain`	Yes	The website domain, e.g. "example.com".

Output Schema

Name	Required	Description	Default
`live`	Yes
`check`	Yes
`domain`	Yes
`message`	Yes
`request`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.29Nov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well past the annotations: it describes exactly what is verified per fix type (structured data on the home page, /llms.txt, /robots.txt), how an unreachable site is treated (`reached` false rather than 'missing'), the one-per-minute throttle with CHECKED_RECENTLY and retry_after, and the subscription/trial requirement. The recording behavior is consistent with readOnlyHint=false, so no contradiction.

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?

Despite its length, it is front-loaded with the core action and trigger, then verification criteria, then failure/throttle semantics, then the subscription caveat. Every sentence carries operational information; the pricing parenthetical is verbose but serves a routing purpose.

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 live-site verification tool with an output schema and non-obvious per-fix-type acceptance criteria, the description covers what an agent needs to call it correctly and interpret results. Nothing material about prerequisites, throttling, or failure modes is missing.

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 the schema already documents both `domain` and `id`; the description's note that the id comes from get_fix or list_fixes largely restates the schema's own wording. It adds no format or validation detail beyond what the schema supplies.

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 object ('check whether a fix is live on the site') and frames it around the owner's claim ('I've added it'), which separates it cleanly from get_fix, list_fixes, and confirm_facts.

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?

Gives explicit trigger phrases ('added, pasted or published', 'is it live', 'did it work') and names where the required `id` comes from (get_fix or a fix's newest request in list_fixes). It also draws a clear boundary against the weekly AI-visibility check and prescribes a fallback (get_sample_audit) when the subscription is absent.

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