VibeDeploy

List custom domains on a site

list_custom_domains

Read-onlyIdempotent

Return all custom domains attached to a site, both those added with add_custom_domain (source 'mcp', with a recordId for verify_custom_domain or remove_custom_domain) and those linked in the VibeDeploy dashboard (source 'dashboard', verified or removed on the dashboard Web Addresses page at manageUrl). Call it before add_custom_domain to avoid adding a domain twice.

Input Schema

Name	Required	Description	Default
`siteName`	Yes	The site whose custom domains to list.

Output Schema

Name	Required	Description	Default
`domains`	Yes
`siteName`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 21, 2026

addedOutput schema / properties / domains / items / properties / manageUrl

Added value: +{
+  "description": "Source 'dashboard' only: the dashboard Web Addresses page where this domain is verified or removed.",
+  "type": "string"
+}

addedOutput schema / properties / domains / items / properties / note

Added value: +{
+  "description": "Source 'dashboard' only: how this entry is managed.",
+  "type": "string"
+}

addedOutput schema / properties / domains / items / properties / recordId / description

Added value: +"Pass to verify_custom_domain or remove_custom_domain. Present on every source 'mcp' entry, absent on source 'dashboard' entries."

addedOutput schema / properties / domains / items / properties / source

Added value: +{
+  "description": "mcp: added with add_custom_domain or the site API. dashboard: linked on the dashboard Web Addresses page.",
+  "enum": [
+    "mcp",
+    "dashboard"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / domains / items / properties / verificationRecord / description

Previous value: -"Only present when status is pending_verification."New value: +"Only present on source 'mcp' entries whose status is pending_verification."

changedOutput schema / properties / domains / items / required

Previous value: -[
-  "recordId",
-  "domain",
-  "status"
-]New value: +[
+  "domain",
+  "status",
+  "source"
+]

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"
+}

First observedJun 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds substantive context the annotations cannot: returned entries carry a source discriminator and a recordId handle usable by verify_custom_domain/remove_custom_domain, and dashboard entries are out of reach of those tools. It does not mention pagination, ordering, or behavior when the site has no domains.

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?

The core action is front-loaded in the first clause, and every subsequent clause (source split, recordId handle, dashboard limitation, dedupe precondition) carries information. It is delivered as one very long sentence, which makes it denser than ideal to parse, but there is no filler.

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?

Given one required parameter, full schema coverage, an output schema, and rich annotations, the description supplies exactly the missing piece: what the two groups of returned domains mean and what the agent can or cannot do with each. Nothing needed to select or invoke the tool correctly is absent.

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% and the single parameter siteName is already documented as 'The site whose custom domains to list.' The description adds no syntax, format, or edge-case guidance for siteName, so the schema does all the work and the 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 ('Return all custom domains attached to a site') and immediately scopes it: both MCP-added and dashboard-linked domains. The mention of the two sources distinguishes it cleanly from add_custom_domain, verify_custom_domain, and remove_custom_domain without needing the schema.

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?

Explicitly says 'Call it before add_custom_domain to avoid adding a domain twice,' giving a concrete precondition and naming the alternative. It also signals the expected follow-on path: dashboard-sourced domains must be verified or removed on the dashboard, while 'mcp' entries carry a recordId for the MCP verify/remove tools.

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.