Delete a DNS domain by ID, including its DNS zone and all subdomains. Destructive operation; requires explicit confirmation and pdns/edit permissions.
Удалить домен по ID: DNS-зону, сам домен и все его сабдомены (pdns/delete_domain). ДЕСТРУКТИВНО. Требует права pdns/edit.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true to run the operation. | |
| domain_id | Yes | ID домена из list_dns_domains | |
| server_id | Yes | ID сервера |
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false, but the description adds value by explicitly labeling the operation as ДЕСТРУКТИВНО and requiring the pdns/edit permission, along with the underlying API call name. This enriches the context beyond the structured hints and contains no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences that front-load the core action, then immediately state the destructive nature and permission requirement. Every word earns its place, and the formatting with capitalization adds emphasis without clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool, the description covers the scope, destructive flag, and permission requirement, which are the key operational constraints. It does not mention the confirm parameter or return values, but the confirm parameter is documented in the schema, and there is no output schema, so these are not critical gaps. The information provided is sufficient for an agent to understand the operation's impact and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already well-documented in the input schema. The description itself does not add further parameter details, leaving the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (delete) and resource (domain by ID), and specifies the full scope: the DNS zone, the domain itself, and all its subdomains. This distinguishes it from sibling tools like delete_dns_subdomain and delete_dns_zone, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the exact scope (domain + zone + subdomains), so an agent can infer it should be used for full domain deletion rather than partial operations. However, it does not explicitly mention alternatives or exclusions, such as 'do not use for deleting only a subdomain', leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.