Website Auditor MCP

Facts to confirm

get_fix_facts

Read-only

Read business facts a site's fixes rely on so owners can review, confirm, or correct them before audit changes are finalized.

Instructions

Read the business facts a site's fixes are written from, as they stand to be confirmed. Use this before confirming facts, to correct facts already confirmed, or after a confirmation answered facts_changed. Returns confirm (each fact with what the site says and what the owner confirmed, confirmed_at, and any facts gone stale), name (the business name the audits found, for the name fact where the site states none), and seen, exactly what the block shows, which confirm_facts sends back unchanged. seen is absent when the facts cannot be confirmed yet (can_confirm false: the site has not been read). The facts are the owner's to confirm: show them to the owner. Reads only. 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
`domain`	Yes	The website domain, e.g. "example.com".

Output Schema

Name	Required	Description
`name`	Yes	The business name the audits found, for the name fact where the site states none; empty when none.
`seen`	No	Absent when the facts cannot be confirmed yet.
`domain`	Yes
`confirm`	Yes	The confirm block: each fact with what the site says and what the owner confirmed.
`message`	Yes
`can_confirm`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.29Nov 5, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Reads only'. It adds genuinely new behavior beyond annotations: the returned fields (confirm, name, seen), the 'seen' absence when can_confirm is false, and the paid Website Auditor prerequisite with trial terms. The pricing parenthetical is long, but the operational disclosures are strong.

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?

The purpose and when-to-use guidance are front-loaded, and the return-shape and prerequisite details follow logically. The subscription sentence is dense and overstuffed with pricing/trial detail, which blunts an otherwise well-structured description.

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?

Complete for a single-parameter read tool: prerequisites, the can_confirm edge case, the meaning of 'seen' being echoed back through confirm_facts, and the owner-facing framing are all covered. The output schema exists, so the description's return-field summary is bonus clarity rather than a gap-filler.

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?

There is only one parameter (domain) and schema description coverage is 100%, so the schema already carries the semantics. The description adds nothing about domain format or validation, making the 3 baseline correct rather than higher.

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 concrete verb and resource ('Read the business facts a site's fixes are written from') and frames the state ('as they stand to be confirmed'), which separates it from confirm_facts and get_fix. An agent can tell it apart from sibling tools without opening 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?

Gives explicit trigger conditions: before confirming facts, to correct already-confirmed facts, or after a confirmation returned facts_changed. It also routes the agent to get_sample_audit when the user lacks a subscription, and gives the free/no-API-key alternative, so no usage decision 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.