Skip to main content
Glama

Delete DNS zone

delete_dns_zone
Destructive

Delete a forward DNS zone. Published zones are queued for removal from the managed DNS platform; the zone's own records are kept on the deletion record, so re-creating the same name in the same account within 7 days publishes it again with…

Instructions

Delete a forward DNS zone. Published zones are queued for removal from the managed DNS platform; the zone's own records are kept on the deletion record, so re-creating the same name in the same account within 7 days publishes it again with those records. A published zone that the domain is delegated to VPSnet for (get_dns_zone: delegation.state=platform) answers for the whole internet: deleting it stops the domain resolving worldwide (websites, e-mail). The API refuses such a delete with HTTP 409 deleteRequiresConfirmation (reason zone_serves_domain, confirm_field confirm_outage, the delegated nameservers) and deletes nothing. Tell the user exactly that and call again with confirm_outage=true only after the user explicitly confirmed the outage; never set it by default or infer it. Requires dns:write when using an API key.

Input Schema

NameRequiredDescriptionDefault
zone_idYesDNS zone ID
confirm_outageNotrue only after the user explicitly confirmed that deleting this zone stops the domain resolving worldwide; required when the API answered deleteRequiresConfirmation. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.18
    • addedInput schema / properties / confirm_outage
      Added value: +{
      +  "default": false,
      +  "description": "true only after the user explicitly confirmed that deleting this zone stops the domain resolving worldwide; required when the API answered deleteRequiresConfirmation. Default false.",
      +  "type": "boolean"
      +}
  2. First observedv2.3.16

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the destructiveHint and openWorldHint annotations by explaining the worldwide resolution impact, the 7-day record retention behavior, the exact HTTP 409 refusal, and the required dns:write scope. This is exactly the behavioral context an agent needs before invoking a destructive tool.

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?

The description is front-loaded with the purpose, then proceeds through consequences, API refusal behavior, confirmation protocol, and permissions. Despite its length, every sentence carries important operational information for a destructive action.

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?

Given the destructive nature, lack of output schema, and 100% schema coverage, the description supplies the remaining critical context: outage consequences, 409 handling, retention behavior, confirmation discipline, and authorization requirements.

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 schema already documents both parameters. The description adds meaningful context for confirm_outage by explaining the 409 deleteRequiresConfirmation condition and the explicit confirmation requirement, though it adds little for zone_id.

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 opens with a specific verb and resource: 'Delete a forward DNS zone.' This clearly distinguishes it from sibling record-level tools such as delete_dns_record and from read/update DNS zone tools.

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?

It gives strong operational guidance on the critical confirm_outage flow: only after explicit user confirmation, never by default or inference. It also points to get_dns_zone delegation state as the condition that triggers the outage warning, though it does not broadly compare this tool against alternative DNS actions.

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