Skip to main content
Glama
oborseth

Official Porkbun MCP Server

Create Webhook

create_webhook

Register a webhook endpoint to receive signed JSON payloads from Porkbun for subscribed events. Returns a secret for verifying the X-Porkbun-Signature header.

Instructions

Register a webhook endpoint. Porkbun will POST a signed JSON payload to url whenever a subscribed event occurs. Returns the new endpoint including its secret — store it securely; it's used to verify the X-Porkbun-Signature header (HMAC-SHA256 over {timestamp}.{rawBody}). url must be a publicly reachable HTTPS endpoint: https:// on port 443, no credentials embedded in the URL, and a hostname that resolves to a public internet address. Private, loopback (including tricks like 127.0.0.1.sslip.io), link-local, CGNAT and reserved addresses are rejected with INVALID_WEBHOOK_URL — do not try to point this at localhost or an internal host. For local development use a public HTTPS tunnel (ngrok, Cloudflare Tunnel) or a sandbox key with sandbox_trigger_webhook. A hostname that does not resolve yet is accepted so you can register before the receiver is deployed, but the rules are re-checked before every delivery. Omit events (or pass ['*']) to subscribe to all event types; you can also pass prefix wildcards like dns.*.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesPublicly reachable HTTPS URL Porkbun will POST event payloads to. Port 443 only; the hostname must resolve to a public internet address (private/loopback/reserved targets are rejected).
eventsNoEvent types to subscribe to, e.g. `['domain.registered','dns.*']`. Omit or use `['*']` for all events. Call get_webhook_event_types for the catalog.

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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses the returned secret, the HMAC-SHA256 signature scheme over {timestamp}.{rawBody}, the exact validation rules, the INVALID_WEBHOOK_URL failure mode, and that rules are re-checked before every delivery. This is unusually rich operational context.

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 core action and the secret-handling warning, and each sentence carries real information. It is dense and somewhat long, but nearly every clause earns its place; only minor tightening 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?

With no output schema, the description compensates by explaining what is returned (the endpoint including its secret). Combined with the URL constraints and event subscription rules, an agent has everything needed to call this correctly.

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, but the description adds rules the schema omits: no credentials embedded in the URL, port 443 only, and the note that an unresolved hostname is accepted at registration. It also restates the events wildcard semantics already in 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 ('Register a webhook endpoint') and immediately scopes the behavior (Porkbun POSTs signed JSON on subscribed events). It is clearly distinguishable from siblings like update_webhook, delete_webhook, and list_webhooks.

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 guidance and named alternatives: use a public HTTPS tunnel (ngrok, Cloudflare Tunnel) or sandbox_trigger_webhook for local development, and it warns against pointing at localhost/internal hosts. Exclusions are concrete rather than implied.

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