Ranla

Create domain

create_domain

Add a sending domain. DNS must still be applied and verified before production sends.

Input Schema

Name	Required	Description	Default
`name`	Yes	Domain name (example.com)
`inbound_enabled`	No	Enable inbound receiving on this domain

Output Schema

Name	Required	Description
`domain`	Yes
`records`	Yes	Sending DNS records to add at the DNS provider
`inbound_note`	No
`inbound_records`	No	Records for inbound receiving
`mail_server_dns_error`	No	Why registering it failed, when it did
`mail_server_dns_synced`	No	True when the domain was registered on the mail server

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "domain": {
+      "properties": {
+        "click_tracking": {
+          "type": "boolean"
+        },
+        "created_at": {
+          "description": "ISO 8601",
+          "type": "string"
+        },
+        "id": {
+          "description": "Domain id",
+          "type": "string"
+        },
+        "inbound_enabled": {
+          "type": "boolean"
+        },
+        "inbound_error": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "inbound_status": {
+          "description": "disabled, pending, active, or error",
+          "type": "string"
+        },
+        "name": {
+          "description": "Domain name",
+          "type": "string"
+        },
+        "open_tracking": {
+          "type": "boolean"
+        },
+        "status": {
+          "description": "Verification status",
+          "type": "string"
+        },
+        "tls_mode": {
+          "type": "string"
+        },
+        "verified_at": {
+          "description": "ISO 8601",
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "id",
+        "name"
+      ],
+      "type": "object"
+    },
+    "inbound_note": {
+      "type": "string"
+    },
+    "inbound_records": {
+      "description": "Records for inbound receiving",
+      "items": {
+        "properties": {
+          "host": {
+            "type": "string"
+          },
+          "priority": {
+            "description": "MX preference",
+            "type": "number"
+          },
+          "purpose": {
+            "description": "What the record is for, e.g. spf, dkim, dmarc",
+            "type": "string"
+          },
+          "type": {
+            "description": "Record type: TXT, CNAME, MX…",
+            "type": "string"
+          },
+          "value": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "host",
+          "value"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "mail_server_dns_error": {
+      "description": "Why registering it failed, when it did",
+      "type": "string"
+    },
+    "mail_server_dns_synced": {
+      "description": "True when the domain was registered on the mail server",
+      "type": "boolean"
+    },
+    "records": {
+      "description": "Sending DNS records to add at the DNS provider",
+      "items": {
+        "properties": {
+          "host": {
+            "type": "string"
+          },
+          "priority": {
+            "description": "MX preference",
+            "type": "number"
+          },
+          "purpose": {
+            "description": "What the record is for, e.g. spf, dkim, dmarc",
+            "type": "string"
+          },
+          "type": {
+            "description": "Record type: TXT, CNAME, MX…",
+            "type": "string"
+          },
+          "value": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "host",
+          "value"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "domain",
+    "records"
+  ],
+  "type": "object"
+}

First observedOct 14, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: that a newly created domain is not production-ready until DNS is applied and verified. It doesn't cover auth requirements or whether creation is idempotent, but the lifecycle caveat is a meaningful addition.

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?

Two short sentences, zero filler, with the core action front-loaded and the prerequisite caveat immediately after. Every sentence earns its place.

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?

An output schema exists, so return values need not be explained. The description covers the action and the critical post-creation prerequisite, which is the main thing an agent needs to avoid a failed production send. It is only slightly thin on the inbound_enabled capability, which is arguably a distinct mode of the tool.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (name, inbound_enabled) are already documented in the schema. The description adds only the framing of 'sending domain' and says nothing about the inbound_enabled toggle, so it does not meaningfully extend parameter meaning beyond the structured fields. Baseline 3 applies.

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?

States a specific verb and resource ('Add a sending domain') with enough scope to distinguish it from siblings like apply_domain_dns, verify_domain, get_domain, and list_domains. An agent can tell immediately that this is the creation step of the domain lifecycle.

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?

The second sentence establishes the workflow context – DNS must be applied and verified before production sends – which implicitly positions apply_domain_dns and verify_domain as the required follow-up steps. It gives clear timing guidance but never names those alternatives explicitly or states when not to use this tool.

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

All Ranla tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?