Website Auditor MCP

Generate JSON-LD schema

generate_schema

Read-only

Generate a tailored JSON-LD schema draft for a website so AI assistants and search engines can better understand its business, product, or FAQ details. Replace placeholder names before publishing.

Instructions

Generate structured data (JSON-LD schema) tailored to a website, to improve how AI assistants and search engines understand it. Use this when someone asks for "schema," "structured data," "JSON-LD," or wants the actual markup to implement a recommendation. Returns a DRAFT, not finished markup: every name field arrives as a placeholder — "Your Business Name" on the business types, and on a Product the product's own name and brand as "Your Product Name" and "Brand Name" — that the owner must replace with real names confirmed with them, never guessed from the domain or copied from an audit. placement_notes says what to replace first, then where to embed the finished snippet, so relay the whole ask and do not tell the user to paste the draft as returned. For a finished fix written from the owner's confirmed facts, with paste steps for their site's platform, use get_fix ("Get this fix") instead: its requests are recorded. 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": "generate_schema"
  }
}

Input Schema

Name	Required	Description	Default
`type`	No	Schema type; "auto" (also the default when omitted) does not detect anything — it returns an Organization draft.
`domain`	Yes	The website domain, e.g. "example.com".

Output Schema

Name	Required	Description	Default
`jsonld`	No	The JSON-LD draft (object or array). NOT ready to paste: every name field arrives as a placeholder — "Your Business Name" on the business types, and on a Product the product's own name and brand as "Your Product Name" and "Brand Name" — that the owner must replace with real names confirmed with them, never guessed from the domain or copied from an audit.
`placement_notes`	Yes	What to replace in the draft first — each name placeholder, confirmed with the owner — then where to embed the finished snippet, e.g. "in the <head> of every page". Relay the whole string, in that order: the replacement ask comes before the placement.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.0.25Oct 1, 2026

changedInput schema / properties / type / description

Previous value: -"Schema type, or auto-detect."New value: +"Schema type; \"auto\" (also the default when omitted) does not detect anything — it returns an Organization draft."

changedOutput schema / properties / jsonld / description

Previous value: -"The JSON-LD document, ready to paste into the site."New value: +"The JSON-LD draft (object or array). NOT ready to paste: every name field arrives as a placeholder — \"Your Business Name\" on the business types, and on a Product the product's own name and brand as \"Your Product Name\" and \"Brand Name\" — that the owner must replace with real names confirmed with them, never guessed from the domain or copied from an audit."

changedOutput schema / properties / placement_notes / description

Previous value: -"Where to put the snippet, e.g. \"in the <head> of every page\"."New value: +"What to replace in the draft first — each name placeholder, confirmed with the owner — then where to embed the finished snippet, e.g. \"in the <head> of every page\". Relay the whole string, in that order: the replacement ask comes before the placement."

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": {
+    "jsonld": {
+      "description": "The JSON-LD document, ready to paste into the site."
+    },
+    "placement_notes": {
+      "description": "Where to put the snippet, e.g. \"in the <head> of every page\".",
+      "type": "string"
+    }
+  },
+  "required": [
+    "placement_notes"
+  ],
+  "type": "object"
+}

First observedv1.0.6Jul 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld=false/non-destructive, but the description adds materially different context: the output is a DRAFT with placeholder name fields that must never be guessed or copied from an audit, `placement_notes` drives the follow-up steps, and the draft must not be relayed as paste-ready. It also discloses the commercial gate ($49/month, 7-day trial, payment method required) and the free no-key fallback. Generating a draft does not contradict readOnlyHint, since nothing is persisted.

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?

Purpose and the DRAFT caveat are front-loaded and nearly every sentence carries operational weight (placeholders, placement_notes, alternative tool, paywall, fallback). It is still one dense unbroken paragraph mixing the draft warning with billing details, which makes the critical placeholder instruction harder to scan than it should be.

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 shape needn't be explained, and the description still covers the things the schema cannot: the draft nature of the output, what must be replaced, how placement_notes is used, the paid access gate, and the free alternative when access is missing. Nothing an agent needs in order to call this correctly is absent.

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 description coverage is 100%, so both parameters are already documented, including the important warning that "auto" detects nothing and falls back to an Organization draft. The description adds no further meaning about `domain` or `type` beyond what the schema states, so the baseline of 3 applies.

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 ("Generate structured data (JSON-LD schema)") plus the scope ("tailored to a website") and the goal ("improve how AI assistants and search engines understand it"). It also distinguishes itself from the nearest sibling by naming get_fix and the different artifact it returns, so an agent can route without opening either schema.

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 an explicit trigger list ("when someone asks for 'schema,' 'structured data,' 'JSON-LD,' or wants the actual markup"), an explicit alternative ("For a finished fix ... use get_fix"), and an explicit prerequisite path (subscription required; if absent, call get_sample_audit first). When-to-use, when-not-to-use, and the fallback are all spelled out.

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