dokploy-mcp-server

dokploy_dns_provider

Manage DNS providers and records for Cloudflare, Route53, Porkbun, OVH, and Infomaniak. Test credentials, list zones, and create, update, or delete A, CNAME, MX, TXT, and other DNS records.

Instructions

DNS provider configuration and DNS record management. Providers: list, get (dnsProviderId), create (name+config), update (dnsProviderId+name+config — the API REPLACES the provider, so both must be sent even when changing one), remove (dnsProviderId), testConnection (dnsProviderId for a saved provider, or config to check credentials before saving). config is discriminated on providerType: cloudflare{apiToken}, route53{accessKeyId,secretAccessKey}, porkbun{apiKey,secretApiKey}, infomaniak{apiToken} or ovh{applicationKey,applicationSecret,consumerKey,endpoint?}. Records: listZones (dnsProviderId), listRecords (dnsProviderId+zoneId), createRecord/updateRecord (dnsProviderId+zoneId+type+recordName+content, ttl?, proxied?, plus recordId for update), deleteRecord (dnsProviderId+zoneId+recordId). Record type: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA or PTR. proxied only takes effect on Cloudflare. Provider credentials are never echoed back in tool output; provider reads return id, name and providerType only.

Input Schema

TableJSON Schema

Name	Required	Description
`ttl`	No
`name`	No	Provider name (letters, digits, _ and - only)
`type`	No	Record type
`action`	Yes
`config`	No	Provider credentials, keyed by providerType
`zoneId`	No
`content`	No	Record value, e.g. an IP for A or a target host for CNAME
`proxied`	No	Cloudflare only: route the record through Cloudflare's proxy
`recordId`	No
`recordName`	No	DNS record name (sent as `name`; distinct from the provider name)
`dnsProviderId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.10.0Oct 3, 2026

changedInput schema / properties / config / oneOf

Previous value: -[
-  {
-    "properties": {
-      "apiToken": {
-        "minLength": 1,
-        "type": "string"
-      },
-      "providerType": {
-        "const": "cloudflare",
-        "type": "string"
-      }
-    },
-    "required": [
-      "providerType",
-      "apiToken"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "accessKeyId": {
-        "minLength": 1,
-        "type": "string"
-      },
-      "providerType": {
-        "const": "route53",
-        "type": "string"
-      },
-      "secretAccessKey": {
-        "minLength": 1,
-        "type": "string"
-      }
-    },
-    "required": [
-      "providerType",
-      "accessKeyId",
-      "secretAccessKey"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "apiToken": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "providerType": {
+        "const": "cloudflare",
+        "type": "string"
+      }
+    },
+    "required": [
+      "providerType",
+      "apiToken"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "accessKeyId": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "providerType": {
+        "const": "route53",
+        "type": "string"
+      },
+      "secretAccessKey": {
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "providerType",
+      "accessKeyId",
+      "secretAccessKey"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "apiKey": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "providerType": {
+        "const": "porkbun",
+        "type": "string"
+      },
+      "secretApiKey": {
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "providerType",
+      "apiKey",
+      "secretApiKey"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "apiToken": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "providerType": {
+        "const": "infomaniak",
+        "type": "string"
+      }
+    },
+    "required": [
+      "providerType",
+      "apiToken"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "applicationKey": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "applicationSecret": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "consumerKey": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "endpoint": {
+        "description": "defaults to ovh-eu",
+        "enum": [
+          "ovh-eu",
+          "ovh-ca",
+          "ovh-us",
+          "kimsufi-eu",
+          "kimsufi-ca",
+          "soyoustart-eu",
+          "soyoustart-ca"
+        ],
+        "type": "string"
+      },
+      "providerType": {
+        "const": "ovh",
+        "type": "string"
+      }
+    },
+    "required": [
+      "providerType",
+      "applicationKey",
+      "applicationSecret",
+      "consumerKey"
+    ],
+    "type": "object"
+  }
+]

addedInput schema / properties / proxied

Added value: +{
+  "description": "Cloudflare only: route the record through Cloudflare's proxy",
+  "type": "boolean"
+}

changedInput schema / properties / type / description

Previous value: -"Record type — the API accepts only A or CNAME"New value: +"Record type"

changedInput schema / properties / type / enum

Previous value: -[
-  "A",
-  "CNAME"
-]New value: +[
+  "A",
+  "AAAA",
+  "CNAME",
+  "MX",
+  "TXT",
+  "NS",
+  "SRV",
+  "CAA",
+  "PTR"
+]

Addedv1.9.1Aug 26, 2026

TDQS

A4.5/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 behavioral burden and does so well. It discloses that update REPLACES the provider (both name and config must be sent), that proxied only affects Cloudflare, that credentials are never echoed back, and exactly what provider reads return.

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 dense but front-loaded and well organized, with separate provider and record action groups. Every sentence adds operational detail, and there is no redundant restatement of the tool name or title.

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?

For an 11-parameter multi-action tool with no output schema and no annotations, the definition is highly complete on inputs and provider read behavior. It could be slightly richer on what zone and record list operations return, but the missing detail is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning beyond the 55% schema coverage: it maps every action to its required parameters, explains the discriminated config shapes per providerType, lists valid record types, clarifies recordName versus provider name, and notes the update caveat that both name and config are mandatory.

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?

The description clearly states the resource and scope: DNS provider configuration and DNS record management, then enumerates every action. It distinguishes the tool from neighboring resources like domains by content, but does not explicitly name or contrast with any sibling tool.

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?

Action-specific guidance is strong: each action is paired with its required identifiers, update semantics are called out, and testConnection is explained for both saved and unsaved credentials. The description does not provide when-not-to-use guidance or point to alternatives among sibling tools.

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

dokploy_dns_provider

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools