Skip to main content
Glama
Postbuild MCP

Postbuild MCP

Official

Provision Stripe Product, Payment Link & Local Checkout Gate

postbuild_checkout

Provision a Stripe Product, USD price, and hosted Payment Link, then write PostbuildCheckoutGate.jsx to the project so you can add checkout and monetization.

Instructions

Provision a Stripe Product, USD Price, and hosted Payment Link (https://buy.stripe.com/...) via STRIPE_SECRET_KEY and write .postbuild/PostbuildCheckoutGate.jsx into cwd. When product_name or description are omitted, metadata is inferred by scraping url; interval switches Price creation between one-time (one_time) and recurring (month/year) billing, while allow_live gates sk_live_ keys (test keys sk_test_ run immediately, whereas live keys abort with LIVE_CONFIRMATION_REQUIRED before any Stripe API call or file write unless the user explicitly requested a live product). Each invocation creates a fresh Stripe Product/Price/Payment Link and overwrites only .postbuild/PostbuildCheckoutGate.jsx. Use this tool when adding Stripe monetization to a project; do not use it to check whether a live site already has checkout (postbuild_scan) or to generate SEO/llms.txt assets (postbuild_fix).

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

Input Schema

NameRequiredDescriptionDefault
cwdNoLocal repository root where `.postbuild/PostbuildCheckoutGate.jsx` is written (defaults to `process.cwd()`).
urlYesTarget project URL used for success/cancel redirects and fallback product metadata (e.g. 'https://your-app.com').
intervalNoBilling cadence: 'one_time' for a single charge, or 'month'/'year' for recurring subscriptions (default: 'one_time').one_time
price_usdNoPrice in whole USD (default: 29, minimum: 1).
allow_liveNoExplicit confirmation to create live Stripe objects when `STRIPE_SECRET_KEY` is an `sk_live_` key (default: false).
descriptionNoCustom Stripe Product description displayed on the hosted Stripe Checkout page.
product_nameNoCustom Stripe Product name (defaults to the target site's title + 'Launch Pass').

Output Schema

NameRequiredDescriptionDefault
okYesTrue when the Stripe Payment Link and local JSX gate component were created.
modeYesStripe environment mode used ('test' for sk_test_ keys, 'live' for sk_live_ keys).
priceIdYesCreated Stripe Price ID (`price_...`).
productIdYesCreated Stripe Product ID (`prod_...`).
checkoutUrlYesHosted Stripe Payment Link URL (`https://buy.stripe.com/...`).
gateFilePathYesAbsolute path to the generated `.postbuild/PostbuildCheckoutGate.jsx` file.
paymentLinkIdYesCreated Stripe Payment Link ID (`plink_...`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv2.1.24
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / allow_live / default
      Added value: +false
    • changedInput schema / properties / allow_live / description
      Previous value: -"Confirm creating a live Stripe product when STRIPE_SECRET_KEY is a live key (default: false). Must come from the user's own explicit words requesting a live Stripe product, never chosen or inferred by the agent."New value: +"Explicit confirmation to create live Stripe objects when `STRIPE_SECRET_KEY` is an `sk_live_` key (default: false)."
    • changedInput schema / properties / cwd / description
      Previous value: -"Local repository path"New value: +"Local repository root where `.postbuild/PostbuildCheckoutGate.jsx` is written (defaults to `process.cwd()`)."
    • changedInput schema / properties / description / description
      Previous value: -"Optional Stripe Product description"New value: +"Custom Stripe Product description displayed on the hosted Stripe Checkout page."
    • addedInput schema / properties / interval / default
      Added value: +"one_time"
    • changedInput schema / properties / interval / description
      Previous value: -"Billing interval: one_time, month, or year (default: one_time)"New value: +"Billing cadence: 'one_time' for a single charge, or 'month'/'year' for recurring subscriptions (default: 'one_time')."
    • addedInput schema / properties / interval / enum
      Added value: +[
      +  "one_time",
      +  "month",
      +  "year"
      +]
    • addedInput schema / properties / price_usd / default
      Added value: +29
    • changedInput schema / properties / price_usd / description
      Previous value: -"Price in USD (default: 29)"New value: +"Price in whole USD (default: 29, minimum: 1)."
    • changedInput schema / properties / product_name / description
      Previous value: -"Optional custom Stripe Product name"New value: +"Custom Stripe Product name (defaults to the target site's title + 'Launch Pass')."
    • changedInput schema / properties / url / description
      Previous value: -"Target project URL (e.g. https://your-app.com)"New value: +"Target project URL used for success/cancel redirects and fallback product metadata (e.g. 'https://your-app.com')."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "checkoutUrl": {
      +      "description": "Hosted Stripe Payment Link URL (`https://buy.stripe.com/...`).",
      +      "type": "string"
      +    },
      +    "gateFilePath": {
      +      "description": "Absolute path to the generated `.postbuild/PostbuildCheckoutGate.jsx` file.",
      +      "type": "string"
      +    },
      +    "mode": {
      +      "description": "Stripe environment mode used ('test' for sk_test_ keys, 'live' for sk_live_ keys).",
      +      "enum": [
      +        "test",
      +        "live"
      +      ],
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "True when the Stripe Payment Link and local JSX gate component were created.",
      +      "type": "boolean"
      +    },
      +    "paymentLinkId": {
      +      "description": "Created Stripe Payment Link ID (`plink_...`).",
      +      "type": "string"
      +    },
      +    "priceId": {
      +      "description": "Created Stripe Price ID (`price_...`).",
      +      "type": "string"
      +    },
      +    "productId": {
      +      "description": "Created Stripe Product ID (`prod_...`).",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "ok",
      +    "mode",
      +    "productId",
      +    "priceId",
      +    "paymentLinkId",
      +    "checkoutUrl",
      +    "gateFilePath"
      +  ],
      +  "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?

Beyond the annotations, it discloses that every call creates a fresh Product/Price/Link (explaining the non-idempotent hint) and that only one file is overwritten. It also documents a non-obvious gate: `sk_live_` keys abort with `LIVE_CONFIRMATION_REQUIRED` before any Stripe API call or file write, while `sk_test_` keys run immediately. That is material operational detail an agent could not infer from the structured fields.

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 is front-loaded in the first clause, followed by side effects, then conditional behavior, then routing guidance — a sensible order. It is a dense single paragraph, and the backtick-heavy identifiers make it slower to scan, but almost every clause carries distinct 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 7-parameter, externally mutating tool, the description covers credentials, side effects, overwrite scope, live-key safety gating, metadata fallback, and sibling routing. With an output schema present and full schema descriptions, nothing needed to invoke it correctly appears to be 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 the baseline is 3, but the description adds real meaning: omitted `product_name`/`description` trigger metadata inference by scraping `url`, and `interval` is tied to switching Price creation between one-time and recurring billing. It does not restate parameter defaults or formats beyond that, so it stops short of a 5.

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?

Names a specific verb (Provision) and concrete resources (Stripe Product, USD Price, hosted Payment Link, local `.postbuild/PostbuildCheckoutGate.jsx`), plus the credential it depends on (`STRIPE_SECRET_KEY`). It also explicitly distinguishes itself from siblings, stating it is not for checking existing checkout (`postbuild_scan`) or SEO assets (`postbuild_fix`).

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-to-use clause ("adding Stripe monetization to a project") and two named exclusions with the sibling that covers each. The `allow_live` behavior also tells the agent the precondition for live keys (explicit user request), which is effectively an invocation guideline.

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