Groundmail

Create domain

create_domain

Add a sending domain. Suggest a subdomain of the company's domain (mail.example.com): the app's email then keeps its own reputation and the team's mailboxes and DNS stay as they are. DNS must still be applied and verified before production sends. Records with already_set are already in place: leave them alone.

Input Schema

Name	Required	Description
`name`	Yes	Domain name, ideally a subdomain (mail.example.com)
`tenant`	No	Give the domain to this tenant; only that tenant can then send from it. The tenant's external id (your id for that customer) or its Groundmail id
`inbound_enabled`	No	Enable inbound receiving on this domain

Output Schema

Name	Required	Description
`domain`	Yes	The domain
`records`	Yes	DNS records to publish for the domain
`inbound_note`	No	Guidance about adding the inbound MX records
`inbound_records`	No	MX records to publish when inbound receiving is enabled

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedOutput schema / properties / domain / properties / blocklists

Added value: +{
+  "description": "Daily check of the domain and its main domain on Spamhaus DBL, SURBL and URIBL. A listing never pauses sending",
+  "properties": {
+    "checked_at": {
+      "description": "When the last daily blocklist check ran (ISO 8601)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "listings": {
+      "description": "Current listings, main domain first",
+      "items": {
+        "properties": {
+          "info_url": {
+            "description": "Where to look the name up and request removal",
+            "type": "string"
+          },
+          "list": {
+            "description": "List name: Spamhaus DBL, SURBL or URIBL",
+            "type": "string"
+          },
+          "list_id": {
+            "description": "List id: spamhaus-dbl, surbl or uribl",
+            "type": "string"
+          },
+          "listed_since": {
+            "description": "When the daily check first found it listed (ISO 8601)",
+            "type": "string"
+          },
+          "name": {
+            "description": "The listed name: the domain itself or its main domain",
+            "type": "string"
+          },
+          "reason": {
+            "description": "What the list says it is listed for, for example spam domain",
+            "type": "string"
+          }
+        },
+        "required": [
+          "list",
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "main_domain": {
+      "description": "The main (registrable) domain",
+      "type": "string"
+    },
+    "names": {
+      "description": "Names checked: the domain and its main domain, or one name for a main domain",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "removed": {
+      "description": "Recent removals, newest first",
+      "items": {
+        "properties": {
+          "info_url": {
+            "description": "Where to look the name up and request removal",
+            "type": "string"
+          },
+          "list": {
+            "description": "List name: Spamhaus DBL, SURBL or URIBL",
+            "type": "string"
+          },
+          "list_id": {
+            "description": "List id: spamhaus-dbl, surbl or uribl",
+            "type": "string"
+          },
+          "listed_since": {
+            "description": "When the daily check first found it listed (ISO 8601)",
+            "type": "string"
+          },
+          "name": {
+            "description": "The listed name: the domain itself or its main domain",
+            "type": "string"
+          },
+          "reason": {
+            "description": "What the list says it is listed for, for example spam domain",
+            "type": "string"
+          },
+          "removed_at": {
+            "description": "When it came off the list (ISO 8601)",
+            "type": "string"
+          }
+        },
+        "required": [
+          "list",
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "description": "Blocklist status: clear, listed, or unknown (not checked yet, not verified, or no list answered)",
+      "type": "string"
+    },
+    "unanswered_lists": {
+      "description": "Lists that did not answer the last check",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "status"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 29, 2026

changedInput schema / properties / name / description

Previous value: -"Domain name (example.com)"New value: +"Domain name, ideally a subdomain (mail.example.com)"

addedOutput schema / properties / inbound_records / items / properties / already_set

Added value: +{
+  "description": "True when the domain already publishes a record that does this job (its own DMARC record). The value is what is there now: nothing to add or change, never publish a second one",
+  "type": "boolean"
+}

addedOutput schema / properties / records / items / properties / already_set

Added value: +{
+  "description": "True when the domain already publishes a record that does this job (its own DMARC record). The value is what is there now: nothing to add or change, never publish a second one",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / tenant

Added value: +{
+  "description": "Give the domain to this tenant; only that tenant can then send from it. The tenant's external id (your id for that customer) or its Groundmail id",
+  "type": "string"
+}

addedOutput schema / properties / domain / properties / tenant

Added value: +{
+  "description": "External id of the tenant that owns the domain. Absent for a domain the whole account can use",
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedOct 16, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare a non-readonly, non-idempotent, open-world mutation, so the bar is lower. The description adds real operational context beyond them: the post-call DNS-and-verification requirement and the instruction to leave already_set records untouched, which prevents a damaging follow-up action.

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 action, then earns its sentences with rationale and a caution. The reputation/DNS justification sentence is explanatory rather than strictly necessary, but it is short and supports the subdomain recommendation.

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 no explanation. The description covers the essential lifecycle (create → apply DNS → verify) and the already_set caution; only the tenant-scoping behavior is left entirely to the schema.

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 coverage is 100%, so all three parameters are already documented, and the description mostly reinforces the subdomain guidance for `name`. It adds no information about the `tenant` scoping parameter or `inbound_enabled`, so baseline 3 is appropriate.

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?

Opens with a specific verb+resource pair ("Add a sending domain"), which unambiguously separates it from list_domains, verify_domain, and apply_domain_dns. It doesn't explicitly name those siblings, so the differentiation is inferred from the verb rather than stated.

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?

Gives clear context on when to use it (fresh domain onboarding) and states the workflow prerequisite that DNS must be applied and verified before production sends, which points the agent toward apply_domain_dns/verify_domain. It stops short of naming alternatives or exclusions explicitly.

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

All Groundmail tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?