Skip to main content
Glama
Sign In
Official Porkbun MCP Server

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Sandbox Key

create_sandbox_key

Create a free throwaway sandbox API key seeded with $1000 fake credit to test Porkbun API calls, DNS changes, and renewals with no real charges or credentials.

Instructions

Instantly create a free SANDBOX API key — NO credentials or approval needed (works before you have any keys). Returns a pk1_sb_ / sk1_sb_ pair for a throwaway test account seeded with $1000 fake credit. Set the returned keys as PORKBUN_API_KEY / PORKBUN_SECRET_API_KEY (or pass them to any tool) and the whole API runs against an isolated sandbox: no real registry actions, DNS changes, certificates, or charges. Ideal for rehearsing register → DNS → renew end-to-end before using a live key. Optional name labels the key.

Input Schema

NameRequiredDescriptionDefault
nameNoOptional label/title for the sandbox key.
scopesNoOptional permissions for the sandbox key, as on a live key (`read` is always included). Omit for full access. Lets you test how your integration behaves with a restricted key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.52.0
    • addedInput schema / properties / scopes
      Added value: +{
+  "description": "Optional permissions for the sandbox key, as on a live key (`read` is always included). Omit for full access. Lets you test how your integration behaves with a restricted key.",
+  "items": {
+    "enum": [
+      "read",
+      "dns",
+      "domains",
+      "email",
+      "hosting",
+      "purchase",
+      "funding",
+      "account"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Addedv0.39.4

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare it non-readonly but non-destructive; the description adds substantial context beyond them: no credentials/approval required, the returned pk1_sb_/sk1_sb_ pair, the $1000 fake-credit seeding, and the isolation guarantee ('no real registry actions, DNS changes, certificates, or charges'). It also explains how to activate the sandbox by wiring the keys into PORKBUN_API_KEY / PORKBUN_SECRET_API_KEY.

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?

Front-loaded with the key fact (free, credential-free) followed by return shape and usage instructions. Dense and mostly efficient, though the setup/env-var sentence and the `name` restatement are slightly redundant given adjacent content.

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 compensates by describing the returned key pair and the seeded credit, plus how to use them. Nothing an agent needs to invoke this correctly or interpret the result 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 parameters are already documented in the schema. The description only restates `name` ('Optional `name` labels the key') and says nothing about `scopes`, adding no meaning beyond the schema. 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+resource ('Instantly create a free SANDBOX API key') and immediately distinguishes it from live key tools by emphasizing 'NO credentials or approval needed (works before you have any keys)'. An agent can tell this apart from request_api_key/retrieve_api_key without opening either 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 conditions ('works before you have any keys', 'Ideal for rehearsing register → DNS → renew end-to-end before using a live key') and implicitly names the alternative ('before using a live key'). The trigger conditions are unambiguous.

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