Skip to main content
Glama
oborseth

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List Domains

list_domains
Read-onlyIdempotent

Retrieve and filter domains in an authenticated Porkbun account by exact name, substring, TLD, expiry, auto-renew, or API access, with key status metadata.

Instructions

List domains in the authenticated Porkbun account. Returns one page (up to 1000) with metadata: expire date, auto-renew, security lock, WHOIS privacy, API access opt-in, and notLocal flag.

Filters (all optional):

  • domain: exact match. Returns 0 or 1.

  • name_contains: substring search on domain name.

  • tlds: limit to these TLDs (no leading dot).

  • expiring_within_days: only domains expiring within N days. Useful for renewal automation.

  • auto_renew: 'yes' or 'no'.

  • api_access: 'yes' or 'no'. Filter to domains an API key can actually operate on — eliminates API_ACCESS_DISABLED errors downstream.

  • sort_name: 'domain' | 'tld' | 'create_date' | 'expire_date'. Default expire_date.

  • sort_direction: 'asc' | 'desc'. Default asc.

For a single domain by name, use get_domain instead — cleaner shape and 404-on-not-found semantics.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tldsNoLimit to these TLDs (no leading dot). Example: ['com', 'io']
startNoPagination offset. Default 0.
domainNoExact domain match — returns 0 or 1 result.
sort_nameNoSort field.
api_accessNoFilter to domains opted in to API access.
auto_renewNoFilter to domains with auto-renew on or off.
name_containsNoCase-insensitive substring on the full domain name.
include_labelsNoInclude user-defined domain labels in the response.
sort_directionNoSort direction.
expiring_within_daysNoOnly domains expiring within this many days from now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations do not: the one-page/1000-item pagination semantics, the specific fields returned, and the downstream error-avoidance rationale for the api_access filter. It does not state what happens when results exceed 1000 (truncation vs. needing `start`), which is the remaining gap.

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-loads purpose and pagination, then a scannable filter list with the sibling redirect last — logical ordering with no filler. It is dense but each bullet carries a distinct constraint or default; only the metadata enumeration is arguably restating return fields.

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 naming the returned metadata fields, and it covers pagination, filtering, sorting and the sibling alternative. An agent has everything needed to call it correctly and interpret the response.

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 genuinely enriches several params beyond the schema: defaults for sort_name/sort_direction, the 'no leading dot' constraint on tlds, the exact-match cardinality of domain, and the practical rationale for api_access. It omits any mention of `start` and `include_labels`, which are schema-only.

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 ('List domains in the authenticated Porkbun account') and immediately scopes the return (one page up to 1000 with named metadata). It also names the sibling it is not, get_domain, so an agent can route 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 routing ('For a single domain by name, use get_domain instead — cleaner shape and 404-on-not-found semantics') plus per-filter intent, e.g. expiring_within_days 'useful for renewal automation' and api_access to eliminate API_ACCESS_DISABLED errors downstream.

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