Skip to main content
Glama

DNS-Eintrag hinzufügen

add_dns_record
Destructive

Legt einen neuen DNS-Record auf einer Domain an (Typen A, AAAA, CNAME, TXT, MX). Für MX-Records ist "priority" zwingend erforderlich (z. B. 10) — Plesk lehnt MX ohne Priorität ab. TXT-Records für SPF, DMARC und DKIM sind ausdrücklich vorgesehen; der Wert darf bis zu 2048 Zeichen lang sein, ein DKIM-Schlüssel passt also vollständig hinein. Ein fehlerhafter Record kann Mail-Zustellung oder Erreichbarkeit der Website beeinträchtigen — bitte Angaben vor der Bestätigung prüfen.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostYesNUR der Name VOR der Domain, ohne den Domainnamen — das Hosting-System hängt die Zone selbst an und prüft nicht, ob sie schon dasteht. Gültig: "www", "_dmarc", "selector1._domainkey", "autodiscover", oder "@" für die Domain selbst. Microsoft 365, Google Workspace und Cloudflare geben DKIM- und DMARC-Hosts dagegen als VOLLSTÄNDIGEN Namen heraus ("selector1._domainkey.example.com", "_dmarc.example.com"), weil das der Name ist, der später abgefragt wird — daraus hier nur den Teil vor der Domain übernehmen: aus "selector1._domainkey.example.com" wird "selector1._domainkey", der Domainname allein ("example.com") wird "@". Wird der Domainname trotzdem mitgeschickt, schneidet der Server ihn ab und die Antwort sagt ausdrücklich, welcher Name entstanden ist; ohne dieses Abschneiden entstünde "selector1._domainkey.example.com.example.com" — ein Eintrag, der als Erfolg gemeldet wird, aber nie abgefragt wird und die Mailauthentifizierung stillschweigend kaputt lässt. Dem Kunden deshalb immer den Namen nennen, der laut Antwort tatsächlich eingetragen wurde, und nicht den, den er genannt hat. Höchstens 255 Zeichen, gezählt nach dem Abschneiden
typeYesRecord-Typ
valueYesZielwert des Records: eine IP-Adresse (A/AAAA), ein Hostname (CNAME/MX) oder der vollständige Textwert (TXT, z. B. "v=spf1 include:_spf.google.com ~all" oder ein DKIM-Wert "v=DKIM1; k=rsa; p=…"). Höchstens 2048 Zeichen. DKIM-Werte unverändert so übernehmen, wie der Anbieter sie ausgibt — auch in der geteilten Schreibweise mit Anführungszeichen ("v=DKIM1; k=rsa; " "p=…"), die wird beim Eintragen automatisch zu einem Wert zusammengefügt. Die 2048 Zeichen zählen für den zusammengefügten Wert
domainYesDie Domain, z. B. example.com
priorityNoPriorität/Gewichtung (nur relevant, meist erforderlich bei MX-Records, z. B. 10)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false. The description adds concrete impact beyond the annotations: a faulty record can break mail delivery or website reachability, and Plesk rejects MX records without a priority. It does not state auth requirements or reversibility, but adds meaningful operational context.

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?

Front-loads the purpose, then covers MX and TXT edge cases and ends with a check-before-confirm warning. Five sentences with no obvious repetition, though some schema details are restated.

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?

Given the rich schema descriptions and destructive annotation, the description is complete enough for safe invocation. It omits authentication/prerequisites and return details, but no output schema exists and the host pitfalls are covered in the schema.

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 parameters are already documented in detail. The description still adds semantic weight by tightening priority from 'usually required' to mandatory for MX and confirming TXT/DKIM usage and the 2048-character limit.

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 ('Legt... an') and resource ('DNS-Record auf einer Domain') plus the supported record types. It implicitly distinguishes creation from sibling delete_dns_record and get_dns_records by the action, but does not name those siblings explicitly.

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

Usage Guidelines2/5

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

No explicit when-to-use or when-not-to-use guidance. It gives a conditional for MX priority and a caution to check details, but does not route the agent between this and alternatives like get_dns_records or delete_dns_record.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources