Skip to main content
Glama

domani

by run.domani

Set DNS Records

set_dns

Upsert DNS records for a domain you own, at the rrset level: records at a (type, name) you send replace that rrset; rrsets you don't mention are preserved (NS never touched). An automatic zone backup is taken before every write. Best practice: call get_dns first and pass its zone_version so a concurrent change fails with DNS_VERSION_CONFLICT instead of being clobbered. Common patterns: Vercel (A @ 76.76.21.21), GitHub Pages (CNAME @ user.github.io), Cloudflare Pages (CNAME @ project.pages.dev)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesDomain name to set DNS records for
recordsYesArray of DNS records to set
zone_versionNoThe zone_version from get_dns - rejects the write with DNS_VERSION_CONFLICT if the zone changed since

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / zone_version
      Added value: +{
+  "description": "The zone_version from get_dns - rejects the write with DNS_VERSION_CONFLICT if the zone changed since",
+  "type": "string"
+}
  2. Changed4 schema fields changed
    • changedInput schema / properties / records / items / properties / name / description
      Previous value: -"Record name, e.g. @ or subdomain"New value: +"Record name, e.g. @ or subdomain (e.g. _443._tcp for TLSA)"
    • changedInput schema / properties / records / items / properties / type / description
      Previous value: -"DNS record type"New value: +"DNS record type (TLSA for DANE)"
    • changedInput schema / properties / records / items / properties / type / enum
      Previous value: -[
-  "A",
-  "AAAA",
-  "CNAME",
-  "MX",
-  "TXT",
-  "NS"
-]New value: +[
+  "A",
+  "AAAA",
+  "CNAME",
+  "MX",
+  "TXT",
+  "NS",
+  "TLSA"
+]
    • changedInput schema / properties / records / items / properties / value / description
      Previous value: -"Record value, e.g. IP address or hostname"New value: +"Record value: IP/hostname, or TLSA rdata like '3 1 1 abc123...'"
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and excels. It discloses the upsert semantics (replaces entire rrset), the preservation of unmentioned rrsets, that NS records are never touched, that an automatic zone backup is taken before every write, and the concurrency conflict behavior (DNS_VERSION_CONFLICT). This is rich behavioral context beyond what a schema could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: the first explains core behavior, the second mentions backup, the third gives concurrency best practice and real-world usage patterns. No fluff or redundancy. Information is front-loaded with the most critical semantics first.

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 mutation tool with no annotations and no output schema, the description covers the essential context: what it does, how it behaves, what safety measures exist (backup), how to avoid conflicts, and what typical use cases look like. It even mentions the required ownership condition. The only minor omission is explicit statement of return values, but this is not critical given the overall completeness.

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% with descriptions for all parameters. The description adds meaningful context beyond the schema: the rrset-level replacement semantics for the records array, the purpose of zone_version (optimistic concurrency), and the domain ownership requirement. It doesn't just repeat schema descriptions.

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 description clearly states the tool's purpose: 'Upsert DNS records for a domain you own, at the rrset level.' It specifies the resource (DNS records for owned domains) and the behavior (replace/upsert at rrset level), distinguishing it from related tools like set_nameservers or get_dns.

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?

Provides explicit usage guidance: 'Best practice: call get_dns first and pass its zone_version so a concurrent change fails with DNS_VERSION_CONFLICT.' It also clarifies scope ('rrsets you don't mention are preserved, NS never touched') and gives common patterns. However, it doesn't name alternative tools for different scenarios (e.g., when to use clone_dns or set_nameservers), so it's clear but not exhaustive.

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

All domani toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation3/5

While most tools have distinct purposes, several clusters overlap significantly (e.g., check_email, check_email_deliverability, get_email_deliverability, get_domain_email_status; buy_domain, buy_aftermarket, acquire_domain). The descriptions are detailed and help differentiate, but the sheer number of tools makes it challenging for an agent to select the correct one without careful reading.

Naming Consistency3/5

The dominant pattern is verb_noun with underscores (e.g., create_mailbox, list_domains), but there are notable inconsistencies: destructive actions mix delete/remove/cancel/revoke/unsell, and a few names deviate entirely (search, dns_check, domain_status). The pattern is recognizable but not uniformly applied.

Tool Count1/5

With 122 tools, this vastly exceeds the 50+ threshold for extreme mismatch. Even for a comprehensive domain and email platform, the tool count is overwhelming and will likely hinder agent performance through excessive choice and context bloat.

Completeness4/5

The server covers a wide range of domains, DNS, email, marketplace, negotiations, transfers, webhooks, tokens, and billing. Minor gaps exist, such as no update operation for mail rules, no direct domain deletion, and limited mailbox configuration beyond forwarding and credentials, but most lifecycle workflows are supported.

Resources