Postbuild MCP

Official

by xdlabs-io

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Generate & Commit Pre-Filled Directory Submission Links

postbuild_dispatch

Idempotent

Prepares pre-filled submission URLs, Show HN titles, and 160-character launch copy for 85 directories, then commits the launch wave with a dry-run preview, commit token, and IndexNow pings.

Instructions

Prepare pre-filled submission URLs, Show HN titles, and 160-character launch copy across 85 directories (or the subset in directory_ids) and ping IndexNow for direct targets, gated by two-phase optimistic concurrency control. Calling with dry_run: true performs a read-only preview against expected_version and issues a single-use HMAC-SHA256 commit_token (ct_...); calling with dry_run: false requires that commit_token plus a valid Launch Pass license (pb_live_...), advancing the domain watermark to v2+ or rejecting stale watermarks/tokens with OCC_REJECTED before any mutation. Committing records dispatch state and pings IndexNow but does not submit external forms requiring human login or CAPTCHAs. Use this tool when preparing and committing a launch wave; do not use it for read-only directory browsing (postbuild_directories) or for clicking email verification links (postbuild_inbox).

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

Input Schema

Name	Required	Description
`url`	Yes	Public HTTP/HTTPS URL of the product being launched (e.g. 'https://your-app.com').
`dry_run`	No	When true (default), runs a read-only preview and returns a `commit_token` (`ct_...`); set false with `commit_token` to commit.
`commit_token`	No	Single-use `ct_...` token returned by a prior `dry_run: true` call; required when `dry_run` is false.
`directory_ids`	No	Optional list of directory IDs (e.g. `['dir-1', 'dir-5']`) to dispatch; omit to target all 85 directories.
`expected_version`	No	Expected domain state watermark (e.g. 'v1') for optimistic concurrency control.

Output Schema

Name	Required	Description
`diff`	No	Preview of state transitions to be applied when committed.
`domain`	Yes	Target project domain.
`status`	Yes	Two-phase execution outcome.
`summary`	No	Committed dispatch batch summary including pre-filled URLs, pitches, and IndexNow status.
`commit_token`	No	Single-use HMAC-SHA256 `ct_...` token issued during `dry_run: true`.
`newWatermark`	No	Incremented state watermark (e.g. 'v2') after `dry_run: false` commits.
`liveWatermark`	No	Current state watermark during `dry_run: true`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv2.1.24Nov 12, 2026

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

changedInput schema / properties / commit_token / description

Previous value: -"Cryptographic ct_... token from dry_run"New value: +"Single-use `ct_...` token returned by a prior `dry_run: true` call; required when `dry_run` is false."

changedInput schema / properties / directory_ids / description

Previous value: -"Optional subset of directory IDs"New value: +"Optional list of directory IDs (e.g. `['dir-1', 'dir-5']`) to dispatch; omit to target all 85 directories."

addedInput schema / properties / dry_run / default
```
Added value: +true
```

changedInput schema / properties / dry_run / description

Previous value: -"Phase 1 preview mode (default: true)"New value: +"When true (default), runs a read-only preview and returns a `commit_token` (`ct_...`); set false with `commit_token` to commit."

changedInput schema / properties / expected_version / description

Previous value: -"Expected version watermark (e.g. v1)"New value: +"Expected domain state watermark (e.g. 'v1') for optimistic concurrency control."

changedInput schema / properties / url / description

Previous value: -"Target URL to dispatch"New value: +"Public HTTP/HTTPS URL of the product being launched (e.g. 'https://your-app.com')."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "commit_token": {
+      "description": "Single-use HMAC-SHA256 `ct_...` token issued during `dry_run: true`.",
+      "type": "string"
+    },
+    "diff": {
+      "description": "Preview of state transitions to be applied when committed.",
+      "type": "object"
+    },
+    "domain": {
+      "description": "Target project domain.",
+      "type": "string"
+    },
+    "liveWatermark": {
+      "description": "Current state watermark during `dry_run: true`.",
+      "type": "string"
+    },
+    "newWatermark": {
+      "description": "Incremented state watermark (e.g. 'v2') after `dry_run: false` commits.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Two-phase execution outcome.",
+      "enum": [
+        "DRY_RUN_APPROVED",
+        "COMMITTED",
+        "OCC_REJECTED",
+        "PRO_LICENSE_REQUIRED"
+      ],
+      "type": "string"
+    },
+    "summary": {
+      "description": "Committed dispatch batch summary including pre-filled URLs, pitches, and IndexNow status.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "status",
+    "domain"
+  ],
+  "type": "object"
+}

First observedv2.1.23Nov 12, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by disclosing the two-phase optimistic concurrency model, the single-use HMAC-SHA256 commit_token, the Launch Pass license requirement (pb_live_...), the OCC_REJECTED failure mode for stale watermarks or tokens, and the scope limit that it does not submit external forms requiring login or CAPTCHAs. What is missing is what state gets recorded or whether a partial dispatch across directories is rolled back on rejection, so it stops short of a 5.

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-loads the resource and scope, then the two-phase mechanics, then the exclusions, which is the right order for an agent scanning for eligibility. It is dense with domain jargon (OCC, watermark, Launch Pass) and the middle sentence is long, but nearly every clause carries operational information and nothing is redundant.

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, gated, open-world tool this covers the full contract: precondition (license), concurrency protocol, token lifecycle, failure code, and an explicit statement of what it does not do. With an output schema present it does not need to describe return values, and the annotations cover the safety profile, so no material gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description adds real meaning: it explains that commit_token is single-use and issued only by a dry_run:true call against expected_version, that dry_run:false requires both the token and a valid license, and that a successful commit advances the domain watermark to v2+, which tells the agent what to pass for expected_version on the next call. This is semantics the schema descriptions alone do not convey.

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 concrete verb-and-resource statement: prepares pre-filled submission URLs, Show HN titles, and 160-character copy across 85 directories, plus IndexNow pings. It immediately scopes the tool against siblings by naming postbuild_directories and postbuild_inbox and the specific jobs they own, so an agent can distinguish it without opening a 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?

Explicitly states when to use it ('when preparing and committing a launch wave') and gives two named when-not cases with the alternative sibling for each: read-only browsing goes to postbuild_directories, email verification links go to postbuild_inbox. The dry_run true/false split further tells the agent which mode to pick for preview versus commit.

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

Deploy Server