Skip to main content
Glama
Official Porkbun MCP Server

Official Porkbun MCP Server

Create Hosting

create_hosting
Destructive

Provision static or WordPress hosting for a domain by plan SKU, starting a 15-day free trial that auto-renews unless canceled. Preview with dry_run before charging.

Instructions

Provision hosting for a domain in the account — Secure Static Hosting OR Cloud for WordPress (a managed WordPress site), chosen by sku. The domain's FIRST provision starts a 15-day FREE trial that auto-renews at the plan price ($3/mo or $30/yr) when it ends; a re-provision after deprovision is charged to account credit (one free trial per domain). Provisioning switches the domain to Porkbun nameservers if it isn't already — set agree_to_nameserver_change: true to allow that. You MUST echo the price in acknowledged_cost_cents (300 monthly / 3000 yearly) so the human is told about the auto-renew/charge. Use dry_run to preview. Provisioning can be async: status may be PENDING — poll get_hosting until ACTIVE before deploying. For a WordPress plan, the file tools (deploy_site/list_hosting_files/…) do NOT apply — manage the site through WordPress instead, using create_wp_credentials to get REST API credentials.

A paid re-provision is a purchase like any other: How a purchase is paid. From prepaid account credit by default; a card saved at Porkbun is never charged by a purchase itself. Or directly, for this one purchase: pay_with_card: true (the user's card from their Stripe Link agent wallet, held and charged only if the purchase succeeds) or pay_with_usdc: true (USDC on Base over x402). If the credit is short, the call fails with INSUFFICIENT_FUNDS carrying cost, balance, shortfall, topUpAvailable and usdcAmountToCover (dry_run: true reports the same without charging). Ways forward, simplest first, always telling the user the dollar amount and getting their OK: (1) if they use Stripe Link, retry this exact call with pay_with_card: true; (2) if you can pay x402 (a wallet tool, or this server has PORKBUN_X402_PRIVATE_KEY), retry with pay_with_usdc: true; (3) when topUpAvailable is true a card is saved: top_up_account_credit (amount_cents at least topUpAmountToCover, or omit it for their configured amount), then retry; (4) add credit with top_up_with_card_mpp (Link) or top_up_with_usdc (for usdcAmountToCover, which allows for Coinbase's ~1% fee), then retry; (5) the user adds credit at https://porkbun.com/account/credit. If a purchase fails with VERIFICATION_REQUIRED, the phone (send_phone_verification_code then confirm_phone_verification) and the email (send_email_verification_code then confirm_email_verification) can both be verified without leaving the conversation, the user reading out each code. Suggest configure_auto_topup if they want credit refilled automatically. Money parameters are integer cents: state amounts to the user in dollars (cost_cents: 1108 is $11.08). If you do not move money on a user's behalf, hand it back instead: tell them the shortfall and that they can add it with buy account credit at https://porkbun.com/account/credit, then retry once they have.

Buying for a new or unfunded account: the whole path, including what only the human can do, is at https://porkbun.com/llms/guides/buy-a-domain-from-an-agent. Paying directly in USDC (no account credit needed): set pay_with_usdc: true. If this server has a wallet configured (PORKBUN_X402_PRIVATE_KEY, local installs only), the payment is signed and the purchase completes in this one call. Otherwise the result is status: PAYMENT_REQUIRED with a checkoutId, an x402Url and a payUrl, and nothing is charged: pay the x402Url with a wallet tool that pays x402 URLs (for example Coinbase's awal x402 pay <x402Url> --scheme auth-capture), or have the user pay the payUrl page, then call this tool again with the same arguments plus usdc_checkout_id. Tell the user the dollar amount first. If the purchase fails after payment, the payment is NOT returned to the wallet: it stays on the Porkbun account as credit (the error says keptAsCredit: true with the new balance), so retry without pay_with_usdc to buy from that credit.

Paying directly by card, with a hold (no account credit needed): set pay_with_card: true when the user pays with Stripe Link. The result is status: PAYMENT_REQUIRED with a payUrl and a cardPaymentId; nothing is charged. Pay the payUrl with an MPP wallet tool. With Link's CLI that is two commands: link-cli mpp pay <payUrl> -X POST --context "..." (context at least 100 characters) creates a spend request the user approves in Link; once approved, complete it with link-cli mpp pay <payUrl> --spend-request-id <lsrq_id> -X POST. That only authorizes the card. If link-cli answers NOT_AUTHENTICATED, run link-cli auth login first (a one-time device login the user approves). Then call this tool again with the same arguments plus card_payment_id: if the purchase succeeds the card is charged, and if it fails the hold is released and nothing is charged. The link works until expiresAt; if that passes before it is paid, call this tool again without card_payment_id for a fresh link instead of paying the old one.

Input Schema

NameRequiredDescriptionDefault
skuYesThe hosting plan SKU to provision. Discover the provisionable SKUs (and each one's price/interval/trial) via list_hosting_plans, then pass the row's `sku`. Secure Static Hosting: `PIXIESECURESTATICM2` ($3.00/mo) / `PIXIESECURESTATICY2` ($30.00/yr). Cloud for WordPress: `CLOUDWORDPRESSM1` ($12.00/mo) / `CLOUDWORDPRESSY1` ($120.00/yr) and the Pro/Business tiers. Link in Bio: `PIXIELINKSM1` ($3.00/mo) / `PIXIELINKSY1` ($30.00/yr); over a free Link in Bio page this upgrades it and keeps its content, then edit it with the *_link_in_bio tools.
domainYesDomain to provision hosting for, e.g. `example.com`.
dry_runNoValidate + preview without provisioning or charging.
pay_with_cardNoPay for this purchase by card from the user's Stripe Link agent wallet (MPP), with a hold: charged only if the purchase succeeds. Tell the user the amount first.
pay_with_usdcNoPay for this purchase directly in USDC on Base (x402) instead of from account credit. Tell the user the amount first.
agree_to_termsYesMust be "yes".
card_payment_idNoThe cardPaymentId from an earlier PAYMENT_REQUIRED (pay_with_card), once its payUrl has been paid. Send it with the same arguments as that call.
usdc_checkout_idNoThe checkoutId from an earlier PAYMENT_REQUIRED result, once its x402Url or payUrl has been paid. Send it with the same arguments as that call.
acknowledged_costNoDeprecated alias of `acknowledged_cost_cents`, same unit (integer US cents). Send `acknowledged_cost_cents` instead.
acknowledged_cost_centsNoThe chosen plan's price — take the `price` field of the SAME row you took `sku` from in list_hosting_plans (e.g. 300 static monthly, 3000 static yearly, 1200 WordPress Starter monthly, 12000 WordPress Starter yearly). Must match exactly or the call is rejected — this confirms the human was told the cost. Required. Integer US cents: 803 means $8.03, not $803.
agree_to_nameserver_changeNoSet true to allow switching the domain to Porkbun nameservers (required when it isn't already on them).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.57.0
    • changedInput schema / properties / sku / description
      Previous value: -"The hosting plan SKU to provision. Discover the provisionable SKUs (and each one's price/interval/trial) via list_hosting_plans, then pass the row's `sku`. Secure Static Hosting: `PIXIESECURESTATICM2` ($3.00/mo) / `PIXIESECURESTATICY2` ($30.00/yr). Cloud for WordPress: `CLOUDWORDPRESSM1` ($12.00/mo) / `CLOUDWORDPRESSY1` ($120.00/yr) and the Pro/Business tiers."New value: +"The hosting plan SKU to provision. Discover the provisionable SKUs (and each one's price/interval/trial) via list_hosting_plans, then pass the row's `sku`. Secure Static Hosting: `PIXIESECURESTATICM2` ($3.00/mo) / `PIXIESECURESTATICY2` ($30.00/yr). Cloud for WordPress: `CLOUDWORDPRESSM1` ($12.00/mo) / `CLOUDWORDPRESSY1` ($120.00/yr) and the Pro/Business tiers. Link in Bio: `PIXIELINKSM1` ($3.00/mo) / `PIXIELINKSY1` ($30.00/yr); over a free Link in Bio page this upgrades it and keeps its content, then edit it with the *_link_in_bio tools."
  2. Changed4 schema fields changedv0.51.1
    • addedInput schema / properties / card_payment_id
      Added value: +{
      +  "description": "The cardPaymentId from an earlier PAYMENT_REQUIRED (pay_with_card), once its payUrl has been paid. Send it with the same arguments as that call.",
      +  "type": "string"
      +}
    • addedInput schema / properties / pay_with_card
      Added value: +{
      +  "description": "Pay for this purchase by card from the user's Stripe Link agent wallet (MPP), with a hold: charged only if the purchase succeeds. Tell the user the amount first.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / pay_with_usdc
      Added value: +{
      +  "description": "Pay for this purchase directly in USDC on Base (x402) instead of from account credit. Tell the user the amount first.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / usdc_checkout_id
      Added value: +{
      +  "description": "The checkoutId from an earlier PAYMENT_REQUIRED result, once its x402Url or payUrl has been paid. Send it with the same arguments as that call.",
      +  "type": "string"
      +}
  3. Addedv0.39.4

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the destructiveHint/write annotations: discloses the 15-day auto-renewing free trial (one per domain), that re-provisioning is charged to credit, the required nameserver switch and its opt-in flag, the async PENDING→ACTIVE lifecycle, hold-and-charge semantics for card, and that failed USDC payments are retained as account credit (keptAsCredit). Error codes (INSUFFICIENT_FUNDS, VERIFICATION_REQUIRED, PAYMENT_REQUIRED) are surfaced with the fields they carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The provisioning-specific content is front-loaded and well-bolded, but the bulk of the text is a generic cross-cutting payment tutorial (top-up routes, link-cli commands, verification flows) that would be identical on every purchase tool. It is organized, yet a large fraction of the word count is boilerplate an agent does not need on every call to this tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-param, destructive, money-moving tool with no output schema, coverage is strong: it explains async status handling, the PAYMENT_REQUIRED round-trip fields (checkoutId, x402Url, payUrl, cardPaymentId, expiresAt), and failure semantics. It stops short of describing the shape of a successful provisioning response, and `agree_to_terms` (required) is never mentioned in prose.

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 schema already carries the per-parameter docs; the description still adds real value by tying `acknowledged_cost_cents` to the exact `price` from the same list_hosting_plans row and explaining why it must match. One flaw: the parenthetical '(300 monthly / 3000 yearly)' states only the static-hosting price while the tool also sells WordPress at 1200/12000, which could mislead an agent choosing a WordPress SKU.

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+resource and enumerates the two product lines ('Secure Static Hosting OR Cloud for WordPress') selected via `sku`. It also routes the agent to the correct siblings by name: list_hosting_plans to discover SKUs, get_hosting to poll status, create_wp_credentials for WordPress plans, and it explicitly says deploy_site/list_hosting_files do NOT apply to WordPress.

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?

Explicit when-to-use and when-not-to-use: dry_run for preview, first-provision vs. paid re-provision, WordPress vs. static file tooling, and a numbered escalation path when credit is short (pay_with_card, pay_with_usdc, top_up_account_credit, top_up_with_card_mpp/usdc, manual top-up). It also names alternatives for VERIFICATION_REQUIRED and PAYMENT_REQUIRED states, leaving little to inference.

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