Skip to main content
Glama

Create or Update a DNS Record

manage_dns_record
Destructive

Create or update (repoint) a single DNS record in a Cycle zone. Use list_dns_zones to inspect zones and records first. This tool cannot delete records — use delete_dns_record for that.

Addressing: pass a full 'domain' (e.g. 'app.example.com' — the covering zone and record name are derived; apex = '@'), or 'zone' plus 'name'. For update, 'record_id' (with 'zone') disambiguates when several records share a name.

Types: a/aaaa (value = IP), cname/alias/ns (value = target domain), mx (value = mail host, priority), srv (value = target, port, priority, weight), txt (value = text), caa (tag + value), linked — a Cycle-managed pointer at a container, tagged deployment, or virtual machine via the 'linked' object; Cycle wires up the IPs, load-balancer routing, and TLS certificates automatically (the environment load balancer must be running for traffic to flow).

Semantics: create NEVER overwrites — an existing record with the same name and type is an error; use action:update to repoint it. update REPLACES the record's whole type payload with what you pass, and records cannot be renamed. In a non-hosted zone, records still configure the load balancer/TLS but the user must manage the zone's public DNS externally.

Always call with preview:true first — it validates and returns a from/to diff, changing NOTHING. Get explicit user confirmation, then call again without preview.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNocaa tag, e.g. 'issue'.
nameNoRecord name within the zone ('@' for apex, '*' for wildcard).
portNosrv port (required for srv).
typeYesRecord type. Also the payload written on update.
zoneNoZone origin (e.g. 'example.com') or 24-char hex ID.
valueNoRecord data: IP for a/aaaa, target domain for cname/alias/mx/ns/srv, text for txt, value for caa. Not used for linked.
actionYescreate adds a new record; update replaces an existing record's type payload (e.g. repointing a linked record).
domainNoFull domain, e.g. 'app.example.com'; the covering zone and record name are derived. Alternative to zone+name.
linkedNoTarget for type 'linked'. Exactly one of: container (optionally + deployment_tag to follow that tagged deployment), or vm.
weightNosrv weight.
contextNoWhy are you calling this tool? Briefly describe the user's goal.
previewNoValidate and return the from/to diff, changing NOTHING. Always run this first; confirm with the user, then call again without preview.
priorityNomx (required) / srv priority.
record_idNoExact record ID for update; disambiguates when several records share a name.
conversation_idNoConversation tracking id. Omit on your first tool call; every result then includes a conversation_id line — pass that exact value on all later calls in this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructiveHint/readOnlyHint annotations, it discloses create-never-overwrites, update-replaces-whole-payload, records-cannot-be-renamed, the preview diff contract, non-hosted-zone DNS implications, and that linked records auto-wire IPs/LB/TLS with a load-balancer-running prerequisite. This is rich behavioral context the annotations cannot convey.

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?

It is long, but front-loaded with purpose and organized into labeled sections (Addressing, Types, Semantics, preview workflow) that a reader can scan. A few sentences restate schema content, so it is not maximally tight, but for a 15-parameter nested tool the length is defensible.

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?

For a complex mutation tool with 15 parameters, a nested linked object, and no output schema, the description covers addressing, per-type payloads, create/update semantics, deletion boundary, and the mandatory preview-confirm flow. Nothing an agent needs to invoke it correctly 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, but the description adds real meaning: the domain-vs-zone+name addressing derivation (apex='@'), record_id disambiguation, and a per-type value format table (mx priority, srv port/weight, caa tag). Some of this overlaps the schema's own value/linked descriptions, which keeps it from a 5.

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?

The opening sentence names a specific verb pair (create/update), the resource (a single DNS record), and the scope (in a Cycle zone). It also explicitly distinguishes itself from siblings list_dns_zones and delete_dns_record, so an agent can route correctly without opening any 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?

It states when to use each alternative: list_dns_zones to inspect first, delete_dns_record for removal, action:update when a record already exists, and the mandatory preview-then-confirm workflow. When-to-use, when-not-to-use, and the correct alternative are all present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources