Skip to main content
Glama
Sign In
OnlyDNS MCP Server

OnlyDNS MCP Server

Official
by Onlydns
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

update_record

Replaces the values and/or TTL of an existing DNS record set for a given name and type, accepting relative, qualified, or canonical FQDN formats.

Instructions

Update an existing DNS record set for a given name and type, completely replacing its values and/or TTL. Accepts relative names (e.g. "testing"), domain-qualified names (e.g. "testing.example.com"), or canonical FQDNs (e.g. "testing.example.com.").

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domainName": "<domainName>",
      "name": "<name>",
      "type": "<type>",
      "value": "<value>"
    },
    "name": "update_record"
  }
}

Input Schema

NameRequiredDescriptionDefault
ttlNoOptional new TTL in seconds (keeps existing TTL if not specified)
nameYesRecord name/subdomain to update. Accepts relative name (e.g. "testing", "www", "@"), domain-qualified name (e.g. "testing.example.com"), or full canonical FQDN (e.g. "testing.example.com."). Canonicalization is handled automatically.
typeYesDNS record type to update (e.g. A, CNAME, TXT)
valueYesNew value(s) for the record. Overwrites existing values for this name and type.
domainNameYesDomain name (e.g. example.com)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.5
    • changedInput schema / properties / name / description
      Previous value: -"Record name/subdomain to update (e.g. \"@\", \"www\")"New value: +"Record name/subdomain to update. Accepts relative name (e.g. \"testing\", \"www\", \"@\"), domain-qualified name (e.g. \"testing.example.com\"), or full canonical FQDN (e.g. \"testing.example.com.\"). Canonicalization is handled automatically."
  2. First observedv1.0.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the key mutation trait that existing values are wholly overwritten rather than merged, and that TTL is preserved when omitted, which is meaningful. However, it is silent on failure modes (what happens if the record does not exist), whether the call is idempotent, permissions/API key needs, or rate limits for a destructive replace.

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?

Two sentences, front-loaded with the operation and its replacement semantics before the naming detail. The second sentence largely restates the `name` parameter description, so it earns only marginal space, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation with no annotations and no output schema, the description covers what the tool does, the destructive replacement scope, and TTL defaulting behavior, and the schema fully documents inputs. The remaining gap is behavior on a missing record and any error/return expectations, which is a moderate but not severe omission.

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 every parameter including the name-format options and TTL preservation is already documented. The description's naming-format sentence duplicates the schema's `name` description almost verbatim, adding no new syntax or constraint information. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Update an existing DNS record set') scoped to a name and type, and clarifies the operation is a full replacement of values and/or TTL. This separates it from an additive tool like add_record, but it never names or contrasts with set_records, delete_record, or add_record, so the sibling boundary is only implied.

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

Usage Guidelines3/5

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

The phrase 'update an existing ... record set' implies the record must already exist, and 'completely replacing' implies the when-not for partial/append flows, but neither is stated. With siblings add_record, set_records and delete_record present, an explicit routing hint (e.g. use add_record to append, delete_record to remove) is missing.

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