VibeDeploy

Attach a custom domain (step 1 of 2)

add_custom_domain

Idempotent

Start attaching a user-owned domain to an existing site: returns the DNS records the user adds at their DNS provider (a routing record that sends visitors here, plus a TXT that proves ownership). Idempotent: the same siteName and domain return the existing record. Once the records are published (usually minutes, up to 24h), call verify_custom_domain with the returned recordId; VibeDeploy also re-checks automatically for a few days and emails the user when the domain is live. The site must already exist; call deploy_site first if it does not.

Input Schema

Name	Required	Description	Default
`domain`	Yes	The user-owned hostname to attach, e.g. 'shop.example.com'. Must be a valid FQDN.
`siteName`	Yes	The VibeDeploy site name to attach the domain to (e.g. 'tester').

Output Schema

Name	Required	Description
`domain`	Yes
`status`	Yes	pending_verification on first attach; verified if the domain was already set up earlier.
`nextCall`	No	Structured hint for the next tool call (e.g. verify_custom_domain). Lets an agent chain without parsing instructions.
`recordId`	Yes	Pass this to verify_custom_domain after the TXT is in place.
`dnsRecords`	No	Every record to add at the DNS provider: routing (sends visitors to VibeDeploy), ownership (TXT) and the optional www/apex twin. Only present when status is pending_verification.
`dnsProvider`	No	The provider that hosts the domain's DNS, recognised from its nameservers. Absent when unknown.
`instructions`	Yes	Plain-English instructions for the user.
`alreadyAttached`	No	True when the call returned an existing record instead of creating one (idempotent path).
`dnsAutoConfigured`	No	True when the verification TXT was written automatically (domain registered through VibeDeploy): call verify_custom_domain right away. Otherwise the user adds the record at their DNS provider first.
`verificationRecord`	No	Only present when status is pending_verification.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

addedOutput schema / properties / dnsProvider

Added value: +{
+  "additionalProperties": false,
+  "description": "The provider that hosts the domain's DNS, recognised from its nameservers. Absent when unknown.",
+  "properties": {
+    "helpUrl": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The provider's own help article on DNS records, when known."
+    },
+    "id": {
+      "type": "string"
+    },
+    "name": {
+      "description": "The company that hosts the domain's DNS, e.g. Combell, OVHcloud, Cloudflare.",
+      "type": "string"
+    },
+    "panelUrl": {
+      "description": "Where the user logs in to edit the DNS records.",
+      "type": "string"
+    },
+    "steps": {
+      "description": "Steps specific to this provider, in order. Relay them with the records.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "panelUrl",
+    "helpUrl",
+    "steps"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 21, 2026

addedOutput schema / properties / dnsRecords

Added value: +{
+  "description": "Every record to add at the DNS provider: routing (sends visitors to VibeDeploy), ownership (TXT) and the optional www/apex twin. Only present when status is pending_verification.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "alternative": {
+        "additionalProperties": false,
+        "properties": {
+          "type": {
+            "type": "string"
+          },
+          "value": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "value"
+        ],
+        "type": "object"
+      },
+      "fqdn": {
+        "type": "string"
+      },
+      "host": {
+        "description": "Value for the provider's Host/Name field ('@' is the domain itself).",
+        "type": "string"
+      },
+      "purpose": {
+        "enum": [
+          "routing",
+          "ownership",
+          "www"
+        ],
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      },
+      "value": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "purpose",
+      "type",
+      "host",
+      "fqdn",
+      "value"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / verificationRecord / properties / host

Added value: +{
+  "description": "What to type in the DNS provider's Host/Name field (e.g. '_vibedeploy.shop'); most providers append the domain themselves.",
+  "type": "string"
+}

changedOutput schema / properties / verificationRecord / properties / name / description

Previous value: -"DNS record name to add (e.g. '_vibedeploy.shop.example.com')."New value: +"Full DNS record name (e.g. '_vibedeploy.shop.example.com')."

Changed3 schema fields changedOct 14, 2026

changedInput schema / properties / domain / description

Previous value: -"The user-owned hostname to attach (e.g. 'tester.subsite.site'). Must be a valid FQDN."New value: +"The user-owned hostname to attach, e.g. 'shop.example.com'. Must be a valid FQDN."

changedOutput schema / properties / dnsAutoConfigured / description

Previous value: -"True when the verification TXT was written automatically because the domain is managed through VibeDeploy's Gandi account. The caller can call verify_custom_domain immediately without waiting for the user to add a TXT manually. Absent / false means the user has to add the record at their own DNS provider before verify will succeed."New value: +"True when the verification TXT was written automatically (domain registered through VibeDeploy): call verify_custom_domain right away. Otherwise the user adds the record at their DNS provider first."

changedOutput schema / properties / verificationRecord / properties / name / description

Previous value: -"DNS record name to add (e.g. '_vibedeploy.tester.subsite.site')."New value: +"DNS record name to add (e.g. '_vibedeploy.shop.example.com')."

Changed1 schema field changedSep 6, 2026

removedOutput schema / properties / request_id

Removed value: -{
-  "description": "Server-assigned request correlation id. Quote it when contacting support.",
-  "type": "string"
-}

Changed1 schema field changedJul 20, 2026

addedOutput schema / properties / request_id

Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}

Changed1 schema field changedJul 2, 2026

changedInput schema / properties / siteName / description

Previous value: -"The vibedeploy.be site name to attach the domain to (e.g. 'tester')."New value: +"The VibeDeploy site name to attach the domain to (e.g. 'tester')."

First observedJun 29, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag idempotentHint=true and destructiveHint=false, but the description adds real substance: the idempotency key (same siteName + domain returns the existing record), DNS propagation timing (minutes up to 24h), automatic re-checking for a few days, and an email notification on success. That is exactly the operational context an agent cannot get from the annotation block.

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?

Three sentences, front-loaded with the action and return payload, then behavior, then sequencing/prerequisite. No sentence is filler; timing and idempotency details are compactly packed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, non-destructive mutation with an output schema, the description covers the remaining burden: what is produced, how long it takes, what the caller does next, and what must exist beforehand. Return-value shape is delegated correctly to the output 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 description coverage is 100%, so both parameters are already documented as domain FQDN and site name. The description reinforces that the domain is user-owned and must be pointed at their DNS provider, but adds no format, validation, or edge-case detail beyond the schema. 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 ('Start attaching a user-owned domain to an existing site') and immediately says what the call returns: the DNS routing record plus ownership TXT record. The title's 'step 1 of 2' framing plus the named follow-up make it unmistakable versus verify_custom_domain or check_domain_availability.

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

Usage Guidelines5/5

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

Gives explicit when-to-use and sequencing: publish the records, then call verify_custom_domain with the returned recordId. It also names the prerequisite ('The site must already exist; call deploy_site first if it does not') and the alternative path when the site is missing.

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

All VibeDeploy tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.