Skip to main content
Glama
Sign In
Postbuild MCP

Postbuild MCP

Official
by xdlabs-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Write Local SEO, AI Crawler, llms.txt & Sitemap Remediation Files

postbuild_fix
Idempotent

Generates missing SEO and AI search readiness files like robots.txt, sitemap.xml, and llms.txt for a scanned URL, writing them into your local repo to close audit gaps.

Instructions

Scan url over HTTPS and write missing technical SEO and AI search readiness artifacts (robots.txt with OAI-SearchBot/ClaudeBot/PerplexityBot allow rules, sitemap.xml, llms.txt, og-card.png, .postbuild/PostbuildCheckoutGate.jsx, and 7 HTML product pages under .postbuild/pseo/) into cwd. url supplies the canonical hostname, title, and metadata embedded into the files written under cwd (public/ or repo root); requires a valid Launch Pass license (pb_live_...) for url's domain and is idempotent and non-destructive by default, preserving any existing user robots.txt/sitemap.xml/llms.txt files and reporting them in skippedFiles. Use this tool when remediating audit gaps in a local repository; do not use it for read-only site audits (postbuild_scan), in-memory HTML page previews (postbuild_pseo), or provisioning live Stripe Payment Links (postbuild_checkout).

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_fix"
  }
}

Input Schema

NameRequiredDescriptionDefault
cwdNoLocal repository directory where missing SEO and `.postbuild/` files are written (defaults to `process.cwd()`).
urlYesProduction HTTP/HTTPS URL scanned for metadata and used in canonical URLs, `sitemap.xml`, and JSON-LD (e.g. 'https://your-app.com').

Output Schema

NameRequiredDescriptionDefault
okYesTrue when local remediation completed without error.
cwdYesResolved local repository root directory.
skippedYesRelative paths of pre-existing user files that were preserved without modification.
writtenYesRelative paths of newly created or updated remediation files.
pseoFilesNoRelative paths of the 7 draft HTML product pages written to `.postbuild/pseo/`.
targetDirNoResolved public static assets directory (`public/` or `cwd`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.1.24
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / cwd / description
      Previous value: -"Local repository path"New value: +"Local repository directory where missing SEO and `.postbuild/` files are written (defaults to `process.cwd()`)."
    • changedInput schema / properties / url / description
      Previous value: -"Production URL for canonical tags"New value: +"Production HTTP/HTTPS URL scanned for metadata and used in canonical URLs, `sitemap.xml`, and JSON-LD (e.g. 'https://your-app.com')."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "cwd": {
+      "description": "Resolved local repository root directory.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "True when local remediation completed without error.",
+      "type": "boolean"
+    },
+    "pseoFiles": {
+      "description": "Relative paths of the 7 draft HTML product pages written to `.postbuild/pseo/`.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "skipped": {
+      "description": "Relative paths of pre-existing user files that were preserved without modification.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "targetDir": {
+      "description": "Resolved public static assets directory (`public/` or `cwd`).",
+      "type": "string"
+    },
+    "written": {
+      "description": "Relative paths of newly created or updated remediation files.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "ok",
+    "cwd",
+    "written",
+    "skipped"
+  ],
+  "type": "object"
+}
  2. First observedv2.1.23

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, openWorld=true; the description adds what annotations cannot: a valid Launch Pass license (`pb_live_...`) bound to `url`'s domain is required, and existing user `robots.txt`/`sitemap.xml`/`llms.txt` are preserved and reported in `skippedFiles`. That skip-reporting contract is exactly the behavior an agent needs before invoking a write tool, and it is consistent with the declared annotations.

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?

Front-loaded with the primary action and destinations, followed by license requirement and then exclusions — a sensible ordering. It is dense with nested parentheses and a long file list, and briefly restates idempotency that annotations already declare, but nearly every clause carries operational information.

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 mutating, open-world tool this covers the prerequisites (license), safety profile (idempotent, non-destructive, skip existing files and report them), output location, and sibling exclusions. With an output schema present, it need not describe return values, so nothing material 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%, so baseline is 3; the description still adds meaning by tying `url` to the license's domain and stating it supplies the canonical hostname, title, and metadata baked into every written file. It also clarifies `cwd` resolution (`public/` or repo root, defaulting to process.cwd()), though the "public/ or repo root" phrasing is slightly ambiguous about which path is actually used.

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 pair and resource: scan `url` over HTTPS and write missing SEO/AI-readiness artifacts, then enumerates the exact files (`robots.txt`, `sitemap.xml`, `llms.txt`, `og-card.png`, `.postbuild/PostbuildCheckoutGate.jsx`, 7 pSEO pages) and their destination `cwd`. This is unmistakably a write/remediation tool and cannot be confused with the sibling scan/preview/checkout 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?

Gives an explicit when: "remediating audit gaps in a local repository." It also gives explicit when-nots with named alternatives — `postbuild_scan` for read-only audits, `postbuild_pseo` for in-memory page previews, `postbuild_checkout` for provisioning Stripe Payment Links — so the agent can route without inspecting other schemas.

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

Deploy Server

Other Tools