Website Auditor MCP

Build a GTM plan from the audit

get_gtm_plan

Build a written go-to-market plan from a website's AI visibility audit, grounded in citation evidence. Steer it with focus, constraints, or a prior plan.

Instructions

Build a written go-to-market plan from a website's latest audit, grounded in its citation evidence. Use this when someone asks "what should I do about my AI visibility," "turn this audit into a plan," or wants a GTM or marketing plan for their site. The plan is built from the sources the assistants actually read — each marked yours, competitor or third_party; competitor sources shape the analysis but are never placement targets. When the audit recorded no citation evidence the plan grounds itself in the report's issues and stats instead. Pass focus or constraints to steer it, and prior_plan (the markdown from an earlier call) to refine rather than start over. Requires a Website Auditor subscription ($10/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

TableJSON Schema

Name	Required	Description
`focus`	No	What to emphasize — e.g. "local directories", "content", "a launch next month".
`domain`	Yes	The website domain, e.g. "example.com".
`prior_plan`	No	The markdown of a plan from an earlier call, to refine instead of starting over.
`constraints`	No	Budget, team, or time constraints — e.g. "solo founder, $200/mo".

Output Schema

TableJSON Schema

Name	Required	Description
`plan`	Yes
`model`	Yes
`domain`	Yes
`summary`	Yes
`sources_used`	Yes
`evidence_note`	No	Additive, never an error: set when the plan had no citation evidence.

Schema Changelog

Changes observed during successful MCP inspections.

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": {
+    "domain": {
+      "type": "string"
+    },
+    "evidence_note": {
+      "description": "Additive, never an error: set when the plan had no citation evidence.",
+      "type": "string"
+    },
+    "model": {
+      "type": "string"
+    },
+    "plan": {
+      "additionalProperties": true,
+      "properties": {
+        "markdown": {
+          "type": "string"
+        },
+        "phases": {
+          "description": "The same plan as `markdown`, cut into 30/60/90-day cards — a rendering, never extra content. An empty array means this plan was not written in card form: render `markdown` instead, and do not report it as a plan without actions. The key being absent means the plan came from a build that predates the cards, which is also not a claim about the plan.",
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "actions": {
+                "description": "Empty for a phase the plan wrote as prose. That is a real plan with nothing cut into cards for this band, not a plan with nothing in it.",
+                "items": {
+                  "additionalProperties": true,
+                  "properties": {
+                    "effort": {
+                      "description": "The plan's own effort estimate, or null when it did not give one. Null means unknown — never render a substitute.",
+                      "type": [
+                        "string",
+                        "null"
+                      ]
+                    },
+                    "goal": {
+                      "type": [
+                        "string",
+                        "null"
+                      ]
+                    },
+                    "priority": {
+                      "description": "Typically \"High\" or \"Medium\"; null when the plan gave none or gave one outside the two the engine keeps. Upstream text, so not an enum here.",
+                      "type": [
+                        "string",
+                        "null"
+                      ]
+                    },
+                    "steps": {
+                      "description": "How to apply it, in order. May be empty.",
+                      "items": {
+                        "type": "string"
+                      },
+                      "type": "array"
+                    },
+                    "title": {
+                      "type": "string"
+                    },
+                    "why": {
+                      "type": [
+                        "string",
+                        "null"
+                      ]
+                    }
+                  },
+                  "type": "object"
+                },
+                "type": "array"
+              },
+              "focus": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "headline": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "name": {
+                "type": "string"
+              },
+              "phase": {
+                "description": "30, 60 or 90 — the day the band closes.",
+                "type": "number"
+              },
+              "range": {
+                "description": "The band as the engine names it, e.g. \"Days 1–30\".",
+                "type": "string"
+              },
+              "short": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "sections": {
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "body_lines": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "title": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "markdown",
+        "sections"
+      ],
+      "type": "object"
+    },
+    "sources_used": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "summary": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "domain",
+    "plan",
+    "sources_used",
+    "model",
+    "summary"
+  ],
+  "type": "object"
+}

Addedv1.0.20Aug 26, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well past the thin annotations by disclosing the grounding behavior (sources tagged yours/competitor/third_party, competitors never placement targets), the no-citation-evidence fallback, and the auth/cost requirement with trial terms. It stops short of describing side effects or whether the generated plan is persisted, which matters given readOnlyHint=false.

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?

Trigger conditions and the core purpose are front-loaded, and every sentence carries distinct information. The subscription parenthetical is the longest stretch and could be trimmed, but it delivers the trial and payment details an agent needs before invoking.

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?

With an output schema present, return-value documentation is unnecessary, and the description covers the remaining agent-relevant gaps: what grounds the plan, the degraded fallback path, steering parameters, and the subscription gate plus its free alternative. Nothing needed to call it correctly 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real interpretation: focus/constraints "steer" the output and prior_plan is specifically the markdown from an earlier call used to refine rather than restart. That clarifies the relationship between parameters in a way the schema alone does not.

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 ("Build a written go-to-market plan from a website's latest audit") and scopes the input as citation evidence from that audit. It is clearly distinguishable from siblings like get_report or get_recommendations, which retrieve rather than synthesize a plan.

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 ("what should I do about my AI visibility", "turn this audit into a plan") and names the alternative path for users without a subscription: call get_sample_audit first. It also distinguishes the refine-vs-restart case via prior_plan, leaving nothing to inference.

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

Deploy Server