Skip to main content
Glama
oborseth

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Setup Mailbox

setup_mailbox

Give a waiting mailbox (already paid for, or the free trial that comes with a domain registration) its address and password. Free.

Instructions

Give a waiting mailbox (already paid for, or the free trial that comes with a domain registration) its address and password. Free. If none is waiting the result is NO_PENDING_MAILBOX: buy one with create_mailbox (with the user's OK on the price). Leave password out and Porkbun generates a strong one and returns it ONCE in password: give it to the user straight away, it is not shown again (it can be changed later with set_email_password). If you pass one, it needs 12-72 characters with an upper case letter, a lower case letter, a number and a special character. A mailbox needs Porkbun's MX records and SPF include at the domain apex (the same records as email forwarding), and the call puts them in place. If that would delete MX records for another mail service or rewrite the domain's SPF record, it returns DNS_CHANGE_CONFIRMATION_REQUIRED with dnsChanges and changes (and charges) nothing: tell the user what will change, and only with their OK call again with confirm_dns_changes: true. The answer includes clientSettings (IMAP/SMTP hosts and ports) for setting up a mail app. DKIM and DMARC are set up on the website. Needs a verified account email and phone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesDomain the mailbox is on, e.g. `example.com`.
addressYesThe mailbox address: the part before the @ (`me`) or the whole address. 1-30 characters: letters, digits and + . - _
dry_runNoIf true, validate and report the DNS changes without setting anything up.
passwordNoOptional. Omit to have a strong password generated and returned once.
mailbox_idNoWhich waiting mailbox, from `list_mailboxes`, when there are several.
confirm_dns_changesNoSet only after the user agreed to the DNS changes a `DNS_CHANGE_CONFIRMATION_REQUIRED` result described.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.51.1

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that DNS records are written at the apex, that the call refuses with `DNS_CHANGE_CONFIRMATION_REQUIRED` when other MX records would be deleted or SPF rewritten, that the generated password is shown only once, and what the response contains (`clientSettings`). The confirmation gate is what keeps the destructive operation from contradicting destructiveHint=false on a normal call, but it is worth noting as a tension.

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

Conciseness5/5

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

It is long but front-loaded and dense – the precondition, the failure code and the confirmation flow are all stated up front, with no filler sentences. The bolded confirmation requirement is placed exactly where an agent needs it.

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 documents the meaningful return signals (`NO_PENDING_MAILBOX`, `DNS_CHANGE_CONFIRMATION_REQUIRED` with `dnsChanges`, the one-time `password`, `clientSettings`) and the prerequisites for a 6-parameter mutation tool. Nothing material 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 baseline is 3, and the description does add real semantics: password omission triggers generation, the 12-72 character complexity rule, and that `confirm_dns_changes` is only set after user agreement on the reported changes. It overlaps the schema somewhat on mailbox_id and dry_run.

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+resource with scope: give an already-waiting mailbox its address and password. It implicitly separates itself from create_mailbox (buying a new one) and set_email_password (changing it later), so an agent can pick correctly without opening the schemas.

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?

Names the exact blocking condition (`NO_PENDING_MAILBOX`) and routes to the alternative (`create_mailbox`, with the user's OK on price), plus the follow-up path for password changes via `set_email_password`. It also states the prerequisite of a verified account email and phone.

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