Skip to main content
Glama
oborseth

Official Porkbun MCP Server

Transfer Domain

transfer_domain
Idempotent

Spends account credit, or pays directly by card (pay_with_card) or in USDC (pay_with_usdc). Initiates a transfer of an external domain into Porkbun.

Instructions

Spends account credit, or pays directly by card (pay_with_card) or in USDC (pay_with_usdc). Initiates a transfer of an external domain into Porkbun. Requires the auth/EPP code from the losing registrar, and cost_cents must match the current transfer price from check_domain. Poll with get_transfer_status. Most transfers finish well inside the five-day worst case — two thirds within 24 hours — so do not promise the user a week. .uk and a few TLDs do not support inbound API transfers. Idempotency-safe.

Set hold_for_dns_setup unless the user has no DNS to preserve. A transfer carries only the delegation, so a domain that moves before its records exist at Porkbun goes dark. Holding charges the transfer but parks it until you release it: hold → prepare_transfer → import_dns_records → start_transfer. Nothing releases a held transfer on a timer.

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

TableJSON Schema
NameRequiredDescriptionDefault
costNoDeprecated alias of `cost_cents`, same unit (integer US cents). Send `cost_cents` instead.
domainYesDomain to transfer in, e.g. `example.com`
dry_runNoIf true, validate and preview (`dryRun: true`, `wouldSucceed`) WITHOUT initiating the transfer or charging.
auth_codeYesAuthorization (EPP) code from the losing registrar.
cost_centsNoTransfer price. Must match the value returned by `check_domain`. Required. Integer US cents: 803 means $8.03, not $803.
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.
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.
hold_for_dns_setupNoCharge the transfer but hold it at PENDINGDNS instead of releasing it, so DNS can be set up before the domain moves. Not supported for .uk/Handshake (returns TRANSFER_HOLD_NOT_AVAILABLE and charges nothing).

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
      +}
  2. Changed7 schema fields changedv0.39.4
    • changedInput schema / properties / cost / description
      Previous value: -"Transfer price in cents. Must match the value returned by `check_domain`."New value: +"Deprecated alias of `cost_cents`, same unit (integer US cents). Send `cost_cents` instead."
    • removedInput schema / properties / cost / exclusiveMinimum
      Removed value: -0
    • addedInput schema / properties / cost / minimum
      Added value: +-9007199254740991
    • addedInput schema / properties / cost_cents
      Added value: +{
      +  "description": "Transfer price. Must match the value returned by `check_domain`. Required. Integer US cents: 803 means $8.03, not $803.",
      +  "exclusiveMinimum": 0,
      +  "maximum": 9007199254740991,
      +  "type": "integer"
      +}
    • addedInput schema / properties / dry_run
      Added value: +{
      +  "description": "If true, validate and preview (`dryRun: true`, `wouldSucceed`) WITHOUT initiating the transfer or charging.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / hold_for_dns_setup
      Added value: +{
      +  "description": "Charge the transfer but hold it at PENDINGDNS instead of releasing it, so DNS can be set up before the domain moves. Not supported for .uk/Handshake (returns TRANSFER_HOLD_NOT_AVAILABLE and charges nothing).",
      +  "type": "boolean"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "domain",
      -  "cost",
      -  "auth_code"
      -]New value: +[
      +  "domain",
      +  "auth_code"
      +]
  3. First observedv0.4.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare idempotent/readOnly/destructive/openWorld. The description goes far beyond: it confirms idempotency safety, explains the 5-day worst case vs. 24-hour typical, discloses the two-phase PAYMENT_REQUIRED hold flow and that failed purchases keep funds as account credit rather than refunding the wallet, and documents INSUFFICIENT_FUNDS/VERIFICATION_REQUIRED error payloads.

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?

The key constraint (spends credit or pays by card/USDC) is bolded and front-loaded, followed by hold semantics and payment mechanics in clearly separated blocks. It is long, but the complexity of 10 parameters and multiple payment rails justifies most of it; minor repetition ('tell the user the amount first' recurs) keeps it from a 5.

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?

Despite no output schema, the description explains the return states an agent must handle (PAYMENT_REQUIRED with payUrl/x402Url, keptAsCredit, dryRun preview, PENDINGDNS hold) and every funding recovery path. Nothing needed to invoke or retry this tool 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%, so the per-parameter definitions already carry the basics. The description still adds real meaning the schema cannot: the required same-arguments resubmission protocol for `card_payment_id`/`usdc_checkout_id`, the release-of-hold semantics, and the cents-vs-dollars requirement for cost_cents. It is above the schema-only baseline but a step short of defining every parameter's edge behavior.

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?

The first sentence states a specific verb and resource: 'Initiates a transfer of an external domain into Porkbun.' It immediately names the sibling it pairs with ('Poll with `get_transfer_status`') and enumerates the required prerequisites (auth/EPP code, cost_cents must match check_domain), so an agent can distinguish it from register_domain or start_transfer 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?

Gives explicit when-to-use guidance for every optional mode: set `hold_for_dns_setup` unless there is DNS to preserve, `pay_with_card` for Stripe Link, `pay_with_usdc` when credit is unnecessary. It also names exclusions (.uk and some TLDs do not support inbound API transfers, .uk/Handshake cannot be held) and routes to alternatives for funding shortfalls.

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