Skip to main content
Glama
Sign In
Official Porkbun MCP Server

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Top Up With Card Mpp

top_up_with_card_mpp

Get a payment link that adds account credit when paid with the user's CARD over MPP (Machine Payments Protocol), using a Stripe Shared Payment Token from their agent wallet (Stripe's Link Agent Wallet).

Instructions

Get a payment link that adds account credit when paid with the user's CARD over MPP (Machine Payments Protocol), using a Stripe Shared Payment Token from their agent wallet (Stripe's Link Agent Wallet). Use it to add credit when a purchase failed with INSUFFICIENT_FUNDS and no card is saved at Porkbun; to pay for just that one purchase, retry it with pay_with_card: true instead, which only charges if the purchase succeeds. Nothing is charged by this call. Pay the returned payUrl with an MPP-capable wallet tool, for example Stripe's Link CLI or its MCP server (link-cli mpp pay <payUrl> -X POST --context "..."). Newer Link CLI versions stop after creating the spend request: once the user approves in Link, run link-cli mpp pay <payUrl> --spend-request-id <lsrq_id> -X POST to complete it. Link rejects a --context shorter than 100 characters, and the payment fails without it: write one or two full sentences the user will read when approving, saying what it is for and the dollar amount (e.g. "Adding $20.00 of prepaid credit to my Porkbun account so my AI assistant can register the domains I asked for."). Word it freshly for each payment; Link can refuse a repeat of an identical request. The link answers 402 with the terms, the wallet asks the user to approve the amount, and the credit is added immediately (the response shows the new balance). Tell the user the dollar amount first. The link is single-use, valid 15 minutes. amount_cents is integer US cents, $5 to $500; same limits as card top-ups. Not available on sandbox keys (use sandbox_topup). If you cannot pay MPP links, top_up_with_usdc or the user adding credit at porkbun.com are the alternatives.

Input Schema

NameRequiredDescriptionDefault
dry_runNoIf true, check eligibility and limits only; creates no link.
amount_centsYesCredit to add, in integer US cents (500 = $5.00). Integer US cents: 803 means $8.03, not $803.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.41.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say not-read-only, open-world, non-idempotent, non-destructive; the description goes far beyond with the single-use 15-minute link, the 402-with-terms flow, the >=100-character `--context` requirement, non-repeat wording rule, that nothing is charged by this call and credit lands immediately, and sandbox unavailability. These are exactly the operational traits annotations cannot express.

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 purpose, fallbacks, and link constraints are front-loaded, and most sentences carry unique operational value (expiry, single-use, context length, CLI submission variants). It runs long and the CLI command examples and Link-version caveat are dense, but nothing is pure padding.

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?

With no output schema, the description still explains what the call returns (`payUrl`, new balance on success, 402 with terms) and covers the full multi-step MPP payment lifecycle an agent must drive. Nothing needed to invoke or complete the flow is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both `amount_cents` and `dry_run` are already documented with min/max, and the description's cents explanation and $5-$500 bound largely restate the schema. It adds some framing (tell the user the dollar amount first, limits match card top-ups) but not much beyond structured data, so the baseline 3 applies.

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 (get a payment link that adds account credit), the payment rail (CARD over MPP via a Stripe Shared Payment Token), and immediately distinguishes itself from the sibling retry path (`pay_with_card: true`) and from `top_up_with_usdc`/`sandbox_topup`. An agent can route correctly 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 an explicit trigger (purchase failed with INSUFFICIENT_FUNDS and no card saved at Porkbun), names the alternative for the one-off case (`pay_with_card: true`, charges only on success), and lists fallbacks (`top_up_with_usdc`, manual top-up at porkbun.com, `sandbox_topup` for sandbox keys). When/when-not/alternatives are all present.

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