Website Auditor MCP

See a sample audit (no key needed)

get_sample_audit

Read-only

Preview a complete sample Website Auditor report for example.com without an API key. See the scored summary, per-test results, and AI-visibility breakdown before subscribing.

Instructions

Show a complete sample Website Auditor report — no API key required, nothing to set up. Use this whenever someone wants to "try it," "see a demo," "show me what this does," "what does the output look like," or is deciding whether Website Auditor is worth subscribing to — and use it INSTEAD of refusing when no API key is configured. Returns fixed sample data for example.com in the exact shape a real audit returns: scored summary, per-test results, and the AI-visibility breakdown by engine. It is clearly marked as a sample and always describes example.com, never the user's own site — auditing a real domain needs a subscription.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_sample_audit"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`note`	Yes
`audit`	Yes	A real GET /api/audit payload, populated with sample data.
`price`	No
`domain`	Yes	The fixed sample domain. Never the caller's own.
`is_sample`	Yes	Always true. Never present this as a live result.
`upgrade_url`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.29Nov 5, 2026

changedOutput schema / required

Previous value: -[
-  "is_sample",
-  "domain",
-  "note",
-  "audit",
-  "price",
-  "upgrade_url"
-]New value: +[
+  "is_sample",
+  "domain",
+  "note",
+  "audit",
+  "upgrade_url"
+]

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": {
+    "audit": {
+      "additionalProperties": true,
+      "description": "A real GET /api/audit payload, populated with sample data.",
+      "properties": {
+        "ai_visibility": {},
+        "base_url": {
+          "type": "string"
+        },
+        "results": {
+          "items": {},
+          "type": "array"
+        },
+        "run_id": {
+          "type": "string"
+        },
+        "status": {
+          "type": "string"
+        },
+        "summary": {}
+      },
+      "type": "object"
+    },
+    "domain": {
+      "description": "The fixed sample domain. Never the caller's own.",
+      "type": "string"
+    },
+    "is_sample": {
+      "const": true,
+      "description": "Always true. Never present this as a live result.",
+      "type": "boolean"
+    },
+    "note": {
+      "type": "string"
+    },
+    "price": {
+      "type": "string"
+    },
+    "upgrade_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "is_sample",
+    "domain",
+    "note",
+    "audit",
+    "price",
+    "upgrade_url"
+  ],
+  "type": "object"
+}

Addedv1.0.15Aug 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds meaningful context beyond them: fixed sample data for example.com, clearly marked as a sample, never the caller's own site, and returned in the exact shape of a real audit. That is exactly the behavior an agent needs to avoid misrepresenting results to a user.

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 action and constraint, then the usage triggers, then return shape. The list of quoted trigger phrases is longer than strictly necessary but each maps to a real user intent and the total remains tight for the guidance it delivers.

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?

An output schema exists, so return values need not be detailed, yet the description still summarizes the returned structure (scored summary, per-test results, AI-visibility breakdown). Combined with the no-key fallback rule and the example.com limitation, nothing an agent needs is missing.

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?

The tool takes zero parameters, so the baseline is 4; the description correctly signals there is nothing to configure ("nothing to set up") and explains why no domain argument exists — it always targets example.com. No further parameter meaning is needed.

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 ("Show a complete sample Website Auditor report") plus a distinguishing constraint ("no API key required") that separates it from get_report and run_audit. An agent can immediately tell this returns demo data rather than a real audit.

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?

Explicitly enumerates when to use it ("try it," "see a demo," "what does the output look like," subscription evaluation) and gives a decisive fallback rule: use it INSTEAD of refusing when no API key is configured. It also states the exclusion — real-domain auditing needs a subscription.

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