Website Auditor MCP

Build a GTM plan from the audit

get_gtm_plan

Read-only

Turn a website audit into a written go-to-market plan grounded in cited evidence. Add focus or constraints to steer it, or pass a prior plan to refine instead of starting over.

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.7/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description reveals how the plan is grounded (citation evidence from sources marked yours/competitor/third_party), the fallback behavior when no citations exist, and the subscription requirement. It even specifies the prerequisite call to get_sample_audit for non-subscribers, providing behavioral context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though fairly long, every sentence earns its place: purpose, use cases, grounding mechanism, fallback, parameter steering, subscription prerequisite, and alternative action are all present without filler. The most important information is front-loaded, and the subscription note is placed logically at the end.

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?

The description covers the main purpose, when to use it, how the plan is grounded, what to do without citations, how to use parameters, and the subscription gate. Since an output schema exists, return-value details are already provided elsewhere, so nothing essential is missing.

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?

Schema coverage is 100%, so the schema already documents all four parameters. The description adds modest interpretive value by explaining that focus/constraints 'steer' the plan and prior_plan is for refining rather than starting over, but it does not provide substantial new detail beyond the schema's own parameter descriptions.

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.' It also provides concrete user-phrase examples ('what should I do about my AI visibility') and clarifies that competitor sources inform but never become placement targets, which distinguishes this tool from recommendation or report tools.

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?

The description explicitly states when to use the tool with quoted user requests and gives situational guidance: use focus/constraints to steer, prior_plan to refine, and call get_sample_audit first if the user lacks a subscription. It clearly tells an agent when to use this tool versus a sibling.

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

Deploy Server