Website Auditor MCP

Confirm business facts

confirm_facts

Confirm the business facts a site's fixes are based on after showing them to the site owner and receiving their explicit confirmation or corrections. Prevents confirming facts on the owner's behalf.

Instructions

Confirm the business facts a site's fixes are written from, as the site's owner confirms them. Use this only after showing the owner the facts get_fix_facts or get_fix returned (the confirm block, with the business name) and getting their own confirmation or corrections: never confirm facts on the owner's behalf, and never without asking them. facts is the owner's answers, keyed by each fact's fact in the confirm block (the business name under "name"); seen is sent back exactly as it was handed out, unchanged, and the confirmation is refused without it. Returns status "confirmed" with the confirmed block and its new seen. When the site's facts changed since they were shown, nothing is confirmed (status "facts_changed", with the facts as they are now): read them again with get_fix_facts and show the owner before confirming. With status "facts_not_read" the site has not been read yet and there is nothing to confirm. Confirmations are capped over any 24 hours (TOO_MANY_CONFIRMATIONS, with retry_after). 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
`seen`	Yes	Exactly the `seen` that came with the facts shown to the owner, unchanged. Without it, or with it changed, nothing is confirmed.
`facts`	Yes	The owner's answers, keyed by each fact's `fact` in the confirm block (the business name under "name"). A fact left out or empty is not confirmed.
`domain`	Yes	The website domain, e.g. "example.com".

Output Schema

Name	Required	Description
`seen`	No	Present when confirmed: what the block shows now, for a later correction; null when the facts cannot be confirmed again now.
`domain`	Yes
`status`	Yes	"confirmed"; "facts_changed": nothing confirmed, the site's facts changed since they were shown (`confirm` is the block as it is now); "facts_not_read": nothing confirmed, the site has not been read yet.
`confirm`	No	The confirm block: each fact with what the site says and what the owner confirmed.
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.29Nov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the concurrency/staleness guard (status 'facts_changed' with guidance to re-read and re-show), the 'facts_not_read' precondition, the hard failure without a matching 'seen', a 24-hour confirmation cap with TOO_MANY_CONFIRMATIONS and retry_after, and the subscription gating. None of this appears in the annotations.

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 purpose and the show-then-confirm rule, and the status enumeration carries genuine information. It is a single dense paragraph with heavy parenthetical nesting, and the closing subscription/trial pricing sentence is verbose relative to its decision value.

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 gated, owner-consent-dependent mutation with nested parameters, the description covers preconditions, failure modes, follow-up actions, and rate limits. An output schema exists, yet the status semantics are still surfaced because they drive the next agent action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning the schema lacks: 'facts' is keyed by each fact's `fact` field from the confirm block (business name under 'name'), and omitted/empty facts are simply not confirmed. The 'seen' explanation largely restates the schema's own wording, which keeps it from a 5.

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 ('Confirm the business facts a site's fixes are written from') plus the authority framing ('as the site's owner confirms them'). It is clearly distinct from the read-only siblings get_fix_facts and get_fix, which are named as prerequisites.

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?

Explicit trigger condition ('only after showing the owner the facts get_fix_facts or get_fix returned'), explicit prohibitions ('never confirm facts on the owner's behalf, and never without asking them'), and an explicit alternative path ('call get_sample_audit first') when the subscription gate blocks use.

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