Website Auditor MCP

Build a GTM plan from the audit

get_gtm_plan

Build a written go-to-market plan from a website’s audit and citation evidence to turn AI-visibility findings into prioritized marketing actions.

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 ($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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "get_gtm_plan"
  }
}

Input 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

Name	Required	Description
`plan`	Yes
`model`	Yes
`domain`	Yes
`summary`	Yes
`dashboard`	No
`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.29Nov 5, 2026

addedOutput schema / properties / dashboard

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "note": {
+      "description": "One line naming what the page shows; the same text is in summary where a reply has one.",
+      "type": "string"
+    },
+    "url": {
+      "description": "The member's own dashboard page.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "url",
+    "note"
+  ],
+  "type": "object"
+}

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

Behavior5/5

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

Beyond the annotations (which only say readOnly=false, destructive=false, openWorld=false), it discloses the paid subscription requirement with pricing and trial terms, the no-evidence fallback grounded in report issues and stats, and the rule that competitor sources shape analysis but are never placement targets. That is context an agent cannot get from structured fields and materially affects how it should set expectations.

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?

It is front-loaded: purpose, then when-to-use, then how the plan is grounded, then parameters, then billing prerequisites. The paragraph is dense but every clause carries operational information; the nested parenthetical pricing detail is the only slightly heavy patch.

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 paid generative tool with four params and an existing output schema, nothing essential is missing: inputs, grounding source, fallback behavior, refinement path and access prerequisites are all covered. Return values need not be described because the output schema handles them.

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 the baseline is 3; the description adds value by framing focus and constraints as steering inputs and prior_plan as "the markdown from an earlier call" used to refine rather than start over. The domain parameter is left implicit (presumably the site whose audit is used), which is the only small gap.

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?

The description opens with a specific verb and resource: "Build a written go-to-market plan from a website's latest audit, grounded in its citation evidence." That distinguishes it immediately from siblings like get_report, get_recommendations and get_ai_visibility, which surface data rather than producing a plan artifact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger phrasings ("what should I do about my AI visibility," "turn this audit into a plan") and names an alternative path: call get_sample_audit first when the user lacks a subscription. It also explains refine-vs-restart via prior_plan, though it doesn't state when to prefer get_recommendations or get_report instead.

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