Skip to main content
Glama
Official Porkbun MCP Server

Official Porkbun MCP Server

Top Up Account Credit

top_up_account_credit

Charges your saved payment card to add funds to your Porkbun account credit, so you can complete a purchase that failed for insufficient funds right away.

Instructions

Charges the user's saved payment method (amount_cents is integer cents: 803 charges $8.03; tell the user the dollar figure first) and adds the money to their Porkbun account credit immediately. Use it when a purchase failed with INSUFFICIENT_FUNDS and the user wants to continue now — enabling auto top-up does not help in that moment, because it only fires on the next order.

It charges the primary card and falls back to the backups if it is declined, charging at most one: the response's card is the one that paid; usedBackup: true means the primary was declined (listed in declinedFirst), so tell the user their primary card needs attention. CARD_DECLINED means every saved card refused (declined lists each with its decline code).

Ask the user before calling, with the figure. This spends real money off a card, not credit they already bought. Omit amount_cents and it charges what the account has configured (or $50 if it never has) — that is the right default, and amountSource in the response says which was used. Pass amount_cents only when the user wants a specific one-off figure, e.g. enough to cover a particular purchase; it does NOT change their saved setting, so prefer it over calling configure_auto_topup for a single charge.

Fails with NO_PAYMENT_METHOD when nothing is saved to charge (the user has to save a card or buy credit on porkbun.com; the API cannot add one), CARD_DECLINED when the card refuses, and TOPUP_LIMIT_EXCEEDED when the month's dollars or the frequency run out — the account's monthly spend limit caps top-up dollars as well as domain spend, an account with no limit set gets $100/month, card, auto, MPP and USDC top-ups all count toward it, and there are 5/day and 20/month count caps. get_auto_topup reports monthlyCeiling, ceilingSource and toppedUpThisMonth, so check there before promising a user a top-up will go through. Every successful charge emails the account holder. A sandbox key grants simulated credit and charges nothing. Supports dry_run, which previews and charges nothing.

Input Schema

NameRequiredDescriptionDefault
amountNoDeprecated alias of `amount_cents`, same unit (integer US cents). Send `amount_cents` instead.
dry_runNoIf true, report what would be charged without charging it.
amount_centsNoOne-off amount to charge, 500-50000. Omit to charge the account's configured top-up amount. Does not change any saved setting. Integer US cents: 803 means $8.03, not $803.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.39.4

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses the card-fallback chain, that at most one card is charged, how to interpret `card`/`usedBackup`/`declinedFirst`/`declined`, the full error taxonomy (NO_PAYMENT_METHOD, CARD_DECLINED, TOPUP_LIMIT_EXCEEDED) with the monthly/daily caps and the $100 default ceiling, the success email side effect, sandbox simulation, and dry_run behavior. This is exactly the real-money/auth context the readOnlyHint=false / destructiveHint=false annotations cannot convey.

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 core action, the money-spending warning, and the dollar-figure instruction are all front-loaded before the operational detail. It is long (five paragraphs) and the caps paragraph is dense, but nearly every sentence carries decision-relevant information; only marginal trimming is possible.

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?

No output schema exists, yet the description explains the relevant response fields (`card`, `usedBackup`, `declinedFirst`, `declined`, `amountSource`) and every failure mode an agent must handle. For a 3-parameter, zero-required mutation tool, nothing an agent needs to call it safely 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 earns extra by explaining the omission semantics in richer terms than the schema ('charges what the account has configured (or $50 if it never has)'), the `amountSource` response field that reports which was used, and the instruction to quote the dollar figure to the user before charging. It does not mention the deprecated `amount` alias, leaving that to the schema.

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 and resource — charges the user's saved payment method and adds the money to their Porkbun account credit — and immediately distinguishes itself from the sibling card/USDC/MPP top-up tools by specifying 'saved payment method' and the primary-card-then-backup routing. An agent can tell exactly what this does and how it differs from configure_auto_topup.

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 trigger ('when a purchase failed with INSUFFICIENT_FUNDS and the user wants to continue now'), an explicit exclusion ('enabling auto top-up does not help in that moment'), and an explicit sibling comparison ('prefer it over calling configure_auto_topup for a single charge'). It also states the precondition of asking the user first, with the dollar figure.

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