Skip to main content
Glama
oborseth

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Top Up Account Credit

top_up_account_credit

Charges your saved card to add credit to your Porkbun account, fixing failed payments with INSUFFICIENT_FUNDS. Confirm the dollar amount with the user before charging.

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.

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 amount_source 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

TableJSON 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.9/5.0
Behavior5/5

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

Well beyond the annotations, it discloses that this spends real money off a card, requires asking the user first, lists concrete failure codes (NO_PAYMENT_METHOD, CARD_DECLINED, TOPUP_LIMIT_EXCEEDED), explains monthly dollar and frequency caps, notes an email is sent, and covers sandbox and dry_run behavior. This is a rich behavioral disclosure for a mutating tool.

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?

Long, but densely packed and front-loaded with the destructive action and the ask-before warning bolded early. Every sentence carries operational weight; only a mild deduction for overall length.

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 covers return signals (amount_source), failure modes, and precondition checks (get_auto_topup's monthlyCeiling/toppedUpThisMonth). An agent has everything needed to call this safely and correctly.

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: the omit-default (configured amount, or $50), that omitting reports back via amount_source, that passing it does NOT change the saved setting, and the cents-vs-dollars unit warning. It turns the schema into actionable semantics rather than restating it.

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 precise verb+resource: charges the user's saved payment method and adds the money to their Porkbun account credit. It clearly distinguishes itself from the related siblings (top_up_with_usdc, top_up_with_card_mpp, configure_auto_topup) by naming them and their differing behavior.

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 ('when a purchase failed with INSUFFICIENT_FUNDS and the user wants to continue now'), an exclusion (auto top-up won't help in that moment, it only fires on the next order), and an alternative routing rule (prefer amount_cents over configure_auto_topup for a single charge). Nothing is left 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