Postbuild MCP

Official

by xdlabs-io

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Audit Live URL for Technical SEO, AI Crawlers & Checkout Readiness

postbuild_scan

Read-onlyIdempotent

Audit a live URL for technical SEO, AI crawler access, llms.txt, sitemap.xml, OpenGraph, JSON-LD, and checkout reachability, then identify failing readiness checks.

Instructions

Execute a read-only 8-point technical SEO, AI crawler (OAI-SearchBot, ClaudeBot, PerplexityBot), llms.txt, sitemap.xml, OpenGraph, JSON-LD, and checkout reachability audit against a live URL. Bare domains in url are normalized to https:// and DNS-resolved through an SSRF guard that rejects loopback, RFC1918 LAN, and cloud metadata IPs before fetching (rate-limited to 10 requests/min; no authentication required; computes the deterministic <slug>@postbuild.dev address without creating server state or local files). Use this tool when evaluating a deployed site's readiness score and failing checks; do not use it to write fix files (postbuild_fix), filter the 85 launch directories (postbuild_directories), or inspect full HTML product page drafts (postbuild_pseo).

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": {
      "url": "<url>"
    },
    "name": "postbuild_scan"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Public HTTP/HTTPS URL or bare domain to audit (e.g. 'https://www.postbuild.dev' or 'cal.com').

Output Schema

Name	Required	Description
`checks`	Yes	Individual pass/fail results for each of the 8 technical SEO, AI crawler, and checkout checks.
`domain`	Yes	Normalized bare hostname extracted from the audited URL (e.g. 'postbuild.dev').
`botEmail`	Yes	Deterministic `<slug>@postbuild.dev` verification inbox address for the audited domain.
`targetUrl`	Yes	Canonical HTTPS URL audited after redirect resolution.
`licenseStatus`	Yes	Whether an active Launch Pass license is configured for this domain.
`directoryCount`	Yes	Total curated directories and launch communities matched for the domain (85).
`pseoRouteCount`	Yes	Number of targeted HTML product pages available for generation (7).
`readinessScore`	Yes	Composite launch readiness score from 0 to 100 across the 8 technical checks.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.1.24Nov 12, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / url / description

Previous value: -"Target URL or domain (e.g. https://www.postbuild.dev)"New value: +"Public HTTP/HTTPS URL or bare domain to audit (e.g. 'https://www.postbuild.dev' or 'cal.com')."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "botEmail": {
+      "description": "Deterministic `<slug>@postbuild.dev` verification inbox address for the audited domain.",
+      "type": "string"
+    },
+    "checks": {
+      "description": "Individual pass/fail results for each of the 8 technical SEO, AI crawler, and checkout checks.",
+      "items": {
+        "properties": {
+          "detail": {
+            "description": "Diagnostic summary or remediation guidance for the check.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Stable check identifier (e.g. 'robots_ai', 'llms_txt', 'sitemap', 'checkout').",
+            "type": "string"
+          },
+          "label": {
+            "description": "Human-readable check name.",
+            "type": "string"
+          },
+          "passed": {
+            "description": "True if the check passed on the live URL.",
+            "type": "boolean"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "directoryCount": {
+      "description": "Total curated directories and launch communities matched for the domain (85).",
+      "type": "number"
+    },
+    "domain": {
+      "description": "Normalized bare hostname extracted from the audited URL (e.g. 'postbuild.dev').",
+      "type": "string"
+    },
+    "licenseStatus": {
+      "description": "Whether an active Launch Pass license is configured for this domain.",
+      "enum": [
+        "PRO_ACTIVE",
+        "FREE_PREVIEW"
+      ],
+      "type": "string"
+    },
+    "pseoRouteCount": {
+      "description": "Number of targeted HTML product pages available for generation (7).",
+      "type": "number"
+    },
+    "readinessScore": {
+      "description": "Composite launch readiness score from 0 to 100 across the 8 technical checks.",
+      "type": "number"
+    },
+    "targetUrl": {
+      "description": "Canonical HTTPS URL audited after redirect resolution.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "domain",
+    "targetUrl",
+    "readinessScore",
+    "botEmail",
+    "licenseStatus",
+    "checks",
+    "pseoRouteCount",
+    "directoryCount"
+  ],
+  "type": "object"
+}

First observedv2.1.23Nov 12, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered structurally. The description still adds substantive behavior: bare-domain normalization to https, DNS resolution through an SSRF guard rejecting loopback/RFC1918/metadata IPs, a 10 req/min rate limit, and no auth requirement. These are real operational constraints, though return shape is delegated to the output schema.

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?

Two sentences, front-loaded with the verb and the audit scope, then the usage routing. The parenthetical stack (rate limit, auth, slug computation, no server state) is dense and slightly overpacked, but every clause carries information an agent would otherwise have to discover by failure.

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?

A single-parameter read-only audit tool with full schema coverage, an output schema for return values, and annotations covering safety. The description adds the guard rails, rate limit, and sibling routing that the structured fields cannot express, so nothing needed to invoke 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 100% and the single parameter is documented in-schema, so the baseline is already met. The description goes beyond it by explaining that bare domains are normalized to https:// and resolved via DNS before fetching, which clarifies accepted input forms and failure modes the schema 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?

Opens with a specific verb ('Execute a read-only 8-point ... audit') and an explicit resource (a live URL), then enumerates the exact check categories: AI crawlers, llms.txt, sitemap.xml, OpenGraph, JSON-LD, checkout reachability. An agent can distinguish this from postbuild_checkout and postbuild_pseo without opening any 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?

States the selection condition ('when evaluating a deployed site's readiness score and failing checks') and names three explicit exclusions mapped to their alternatives: postbuild_fix for writing fixes, postbuild_directories for filtering, postbuild_pseo for HTML drafts. When-to-use and when-not-to-use are both present with routing.

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

Deploy Server