Skip to main content
Glama

turbopress

by de.turbopress.mcp
OverviewDiscussionsAdmin

DNS-Eintrag löschen

delete_dns_record
Destructive

Löscht EINEN DNS-Eintrag einer Domain — der Weg zurück zu add_dns_record, etwa für einen falsch eingetragenen DKIM-, SPF- oder DMARC-Wert. Die Kennung (record_id) muss aus get_dns_records stammen und wird serverseitig gegen die Zone genau dieser Domain geprüft; eine geratene oder aus einer älteren Antwort übernommene Kennung wird abgewiesen, bevor irgendetwas gelöscht wird. Die Kennungen sind nicht stabil: vor dem Löschen get_dns_records frisch abrufen und dem Kunden Typ, Name und Wert des Eintrags nennen, den er löschen will. Ein gelöschter Eintrag lässt sich über dieses Werkzeug nicht wiederherstellen, nur mit add_dns_record neu anlegen — und ein fehlender SPF-, DKIM- oder MX-Eintrag kann Mailzustellung oder Erreichbarkeit der Website sofort beeinträchtigen. Die Antwort sagt ausdrücklich, ob der Eintrag nach dem Löschen wirklich aus der Zone verschwunden ist; ist die Zone danach nicht abrufbar, meldet sie das als ungeprüft statt als Erfolg.

Input Schema

NameRequiredDescriptionDefault
domainYesDie Domain, z. B. example.de
record_idYesKennung des Eintrags, genau wie von get_dns_records geliefert — keine geratene Zahl, und keine aus einer früheren Antwort
bestaetigungNoNur für geschützte Einträge (MX, SPF, DKIM, DMARC, A/AAAA der Hauptdomain und von www, sowie die Ziele eines MX): der VOLLE Name des Eintrags, genau wie ihn die Fehlermeldung nennt (Feld required_name). Ohne diese Angabe lehnt der Server mit confirmation_required ab und löscht nichts. NS und SOA lassen sich nie löschen. Den Namen nur setzen, nachdem der Kunde das Löschen ausdrücklich bestätigt hat — nie vorsorglich mitschicken.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / bestaetigung
      Added value: +{
+  "description": "Nur für geschützte Einträge (MX, SPF, DKIM, DMARC, A/AAAA der Hauptdomain und von www, sowie die Ziele eines MX): der VOLLE Name des Eintrags, genau wie ihn die Fehlermeldung nennt (Feld required_name). Ohne diese Angabe lehnt der Server mit confirmation_required ab und löscht nichts. NS und SOA lassen sich nie löschen. Den Namen nur setzen, nachdem der Kunde das Löschen ausdrücklich bestätigt hat — nie vorsorglich mitschicken.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

While annotations already flag the tool as destructive, the description adds substantial operational context: server-side validation against the zone of the exact domain, rejection of guessed or stale IDs before any deletion, ID instability requiring a fresh get_dns_records call, irreversibility (only add_dns_record can recreate), and potential immediate impact on mail delivery or website availability. It further describes response semantics, including that an inaccessible zone is reported as unverified rather than success.

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?

The purpose is front-loaded in the first clause, and the remaining sentences each add operational detail without filler. The description is dense and somewhat long, but for a destructive operation with real service-impact warnings this level of detail is justified rather than wasteful.

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 tool's destructive nature, three parameters, and lack of an output schema, the description covers everything an agent needs: correct identifier sourcing, server-side validation, confirmation requirements, irreversibility, potential service impact, and the meaning of the response including unverified outcomes. No critical pre-invocation information 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 description coverage is 100%, so the schema already documents all three parameters well, making 3 the baseline. The description still adds meaning beyond the schema by explaining that record_id is validated server-side against the zone of that domain and that guessed or stale identifiers are rejected before anything is deleted, plus it reinforces ID instability and the need to fetch fresh values before calling.

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 precise verb and resource: 'Löscht EINEN DNS-Eintrag einer Domain'. It immediately distinguishes the tool from siblings by naming add_dns_record as the reversal path and get_dns_records as the source of the required identifier. An agent can tell this apart from other delete_* tools and from add_dns_record without opening a 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 explicitly states the use case ('der Weg zurück zu add_dns_record, etwa für einen falsch eingetragenen DKIM-, SPF- oder DMARC-Wert') and names the sibling tool to use for recreation. It also provides prerequisites: fetch fresh IDs via get_dns_records, show the customer type/name/value before deleting, and obtain explicit confirmation before sending the bestaetigung field. It even notes that NS and SOA records can never be deleted.

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

All turbopress toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources