Skip to main content
Glama
oborseth

Official Porkbun MCP Server

by oborseth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update DNS Record

update_dns_record
DestructiveIdempotent

Change an existing DNS record's type, content, TTL, or priority using its record_id. Alerts you if the domain's nameservers aren't Porkbun's.

Instructions

Update an existing DNS record by its numeric record_id (obtained from list_dns_records). All fields except record_id and domain are optional — pass only the ones you want to change. Idempotent: applying the same update twice is a no-op.

Check warnings in the response and pass it on. Porkbun keeps a DNS zone for every domain in the account whether or not the domain is delegated to Porkbun's nameservers, so this write succeeds either way. If the domain points somewhere else, the response is still SUCCESS but carries a warnings string naming the nameservers that actually answer — the record exists and nothing resolves differently. Do not report plain success in that case: either make the change at the provider that runs those nameservers, or offer update_nameservers to point the domain at Porkbun.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ttlNoNew TTL in seconds.
nameNoNew subdomain prefix (empty string = apex).
prioNoNew priority (MX/SRV only).
typeNoNew record type (rarely changed).
domainYesDomain the record belongs to, e.g. `example.com`
contentNoNew record value.
dry_runNoIf true, validate only — confirms the record exists and is editable, returns wouldSucceed without changing it.
record_idYesNumeric record ID (as a string). Get this from `list_dns_records`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.39.4
    • addedInput schema / properties / dry_run
      Added value: +{
+  "description": "If true, validate only — confirms the record exists and is editable, returns wouldSucceed without changing it.",
+  "type": "boolean"
+}
  2. First observedv0.4.1

TDQS

A4.4/5.0
Behavior5/5

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

With annotations already covering idempotent/destructive/readOnly, the description adds real value beyond them: it explains the Porkbun-keeps-a-zone-anyway behavior, that a write can return SUCCESS yet not resolve because another nameserver answers, that `warnings` must be checked and propagated, and that `dry_run` returns `wouldSucceed`. These are non-obvious operational traits an agent cannot infer from structured fields.

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 purpose and the record_id sourcing, then a bolded behavioral caveat. The nameserver/warnings paragraph is longer than typical but each sentence carries decision-relevant information (what SUCCESS-with-warnings means, what to do instead). Minor verbosity, but nothing clearly expendable.

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, so the description carries the return burden and does so: it names the `warnings` field, the SUCCESS status, and `wouldSucceed` for dry runs. Combined with annotations covering safety and idempotency and full schema coverage, an agent has everything needed to call it and interpret the result correctly.

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 the schema already documents each parameter (ttl, name, prio, content, etc.). The description adds the useful rule that all fields except `record_id` and `domain` are optional and only changed fields need passing, but this largely restates the schema's `required` list. Baseline 3 is appropriate.

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 (Update) and resource (an existing DNS record) and pins the targeting key: the numeric `record_id`. The word 'existing' implicitly separates it from `create_dns_record`/`delete_dns_record`, and it explicitly names `list_dns_records` as the source of the ID, so an agent can tell what it does and how to aim it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: use it to modify an already-existing record, pass only the fields to change, and use `dry_run` to validate first. It also routes to an alternative (`update_nameservers`) when the domain isn't delegated to Porkbun. It stops short of explicit when-not-to-use framing, but the guidance is concrete and actionable.

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