Website Auditor MCP

Get this fix

get_fix

Serves ready-to-paste site fixes—structured data, llms.txt, and robots.txt lines—with platform-specific steps, using confirmed business facts and audit findings.

Instructions

"Get this fix": a site fix served finished, with paste steps for the platform the site runs on: the business-facts structured data and the llms.txt are written from the facts its owner confirmed; the robots.txt lines from what the newest audit found blocked. Use this when someone asks to "get this fix," "do it for me," "give me the structured data / llms.txt / robots.txt lines to paste," or wants a fix done rather than described. Returns status "served" with the request (its id is what check_fix checks) and the fix: each block ready to copy, the steps for the site's platform (or the platform given), and copy_all, the prompt and every block in one paste, where the steps carry a prompt for the agent that edits the site. Each call is recorded as a request for the fix. When the newest audit found nothing for the fix to change (for robots_txt, no AI assistant blocked), it returns status "nothing_to_fix" and records nothing. Nothing that states the owner's facts is served before the owner has confirmed them: then it returns status "confirm_first" with the reason, the confirm block and seen — show the owner those facts, and once they confirm or correct them, call confirm_facts with seen unchanged and ask again. With reason "facts_not_read" the site has not been read yet, so there is nothing to confirm until its next weekly check. It answers only for a site the account tracks. 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
`kind`	No	Which fix: "business_facts" (structured data plus About and FAQ text, from the owner's confirmed facts), "llms_txt" (an llms.txt titled with the confirmed name), or "robots_txt" (Allow lines for the AI assistants the newest audit found blocked by robots.txt; it states no facts, so nothing is confirmed first). Left out, the site's top fix.
`domain`	Yes	The website domain, e.g. "example.com".
`platform`	No	The platform to write the steps for, one of the `platforms` keys in the site's fix list (e.g. "wordpress", "shopify", "developer_host"). Left out, the platform detected for the site.

Output Schema

Name	Required	Description
`fix`	No	Present when served.
`seen`	No	Present on confirm_first when the owner can answer it.
`domain`	Yes
`reason`	No	Present on confirm_first: "unconfirmed", "stale" (the site changed a confirmed fact), "no_name", or "facts_not_read" (the site has not been read, so nothing can be confirmed yet).
`status`	Yes	"served": the fix, finished. "confirm_first": nothing served; the facts it states are not confirmed by the owner yet. "nothing_to_fix": nothing served; the site's newest audit found nothing for this fix to change.
`confirm`	No	The confirm block: each fact with what the site says and what the owner confirmed.
`message`	Yes
`request`	No	Present when served: the request this call was recorded as.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.29Nov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description supplies the missing context: each call is recorded as a request for the fix (the side effect that justifies the non-read-only hint), nothing is recorded when the status is nothing_to_fix, and no owner-stated fact is served before the owner confirms it. It further discloses a hard prerequisite (Website Auditor subscription, $49/month, trial terms) and the fact that the tool answers only for tracked sites.

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 'what' and the trigger condition before branching into statuses, so an agent can stop reading early if the happy path is enough. The downside is a single ~300-word paragraph of run-on sentences with mid-clause parentheticals, which makes the status branches harder to scan than a short list would be.

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?

Covers everything an agent needs for a non-read-only tool that can refuse: the success shape, each failure status with its follow-up action, the recording side effect, the precondition, and the billing gate. Return values are additionally backed by an output schema, so the description is complete without duplicating field-level detail.

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% and every parameter already carries a description, including defaults (kind left out = top fix; platform left out = detected platform). The description reinforces the impact of these choices but adds little syntactic or format meaning beyond what the schema states, so the baseline of 3 for full schema coverage applies.

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 — it serves a finished site fix with paste steps, plus the platform-specific instructions and copy_all bundle. It also distinguishes itself from siblings by naming check_fix (which checks the returned request id), confirm_facts (which handles the confirm_first branch) and get_sample_audit (the no-subscription fallback).

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 ('get this fix', 'do it for me', 'give me the structured data / llms.txt / robots.txt lines to paste') and an explicit contrast with wanting a fix 'described' rather than done. It also routes each non-happy path: nothing_to_fix, confirm_first (call confirm_facts with `seen` unchanged), facts_not_read (wait for the next weekly check), and no-subscription (call get_sample_audit first).

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