domain-setup-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DOMAIN_SETUP_HOME | No | Override for the directory where plans and run logs are stored (defaults to ~/.domain-setup-mcp). | |
| CLOUDFLARE_API_TOKEN | Yes | Cloudflare API token. Requires Zone: Read, DNS: Edit, and Single Redirect: Edit (listed as Dynamic URL Redirects Write) if using forward_to. Scope it to the specific zones you are setting up. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Sets up SPF, DKIM, DMARC, MX, verification TXT, tracking CNAMEs and website forwarding for cold email domains on Cloudflare. Workflow: domain_audit -> domain_plan -> show the user the diff -> domain_apply(confirm=true) only after the user approves -> domain_verify. Never call domain_apply or domain_rollback with confirm=true without explicit user approval of that exact plan. DKIM keys, verification codes and Microsoft MX values are unique per domain: ask the user for them and pass them under config.per_domain; never invent or reuse them across domains.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| domain_auditA | Check SPF, DKIM, DMARC and MX on public DNS for each domain. Read-only; needs no Cloudflare token. |
| domain_planA | Build a reviewable diff of DNS changes per domain. Writes nothing to DNS. Merges into existing SPF (never adds a second record), blocks plans over the 10-lookup limit, never overwrites live MX unless replace_mx=true, never changes an existing DMARC policy, and never guesses Microsoft MX or DKIM values. Per-domain values go in config.per_domain. Returns a plan_id. |
| domain_applyA | Apply a saved plan to Cloudflare. Each domain's DNS changes go in one atomic batch (all or nothing). Skips any domain whose DNS changed since the plan was made. Returns run_id for domain_rollback. |
| domain_verifyC | Check that every planned change is visible on public DNS and that forwarding answers with its 301. |
| domain_rollbackA | Undo every change made by one domain_apply run, in reverse order. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool maps to a distinct phase of the DNS lifecycle: audit (read-only pre-check), plan (dry-run diff), apply (write), verify (post-check), rollback (undo). Audit vs. verify could superficially overlap but descriptions clearly separate pre-state inspection from post-apply confirmation.
All five tools use a uniform `domain_` prefix with a single descriptive verb (audit, plan, apply, verify, rollback). Perfectly predictable pattern.
Five tools is well-scoped for a plan-then-apply DNS workflow; each tool earns its place with no redundancy or filler.
The audit→plan→apply→verify→rollback lifecycle is fully covered, including atomic batching and state-change guards. Minor gaps exist: no tool to list/inspect saved plans by plan_id or run_id, and no way to remove domains from management outside a planned change.