VibeDeploy

Get site details

get_site

Read-onlyIdempotent

Return one site's details: live URL, status, plan, served file paths, whether editable source is stored (and its build settings), custom domains, bandwidth and the last 10 deploys. Use get_site to inspect a site before editing it; use list_sites to find site names, and get_app_status for container services.

Input Schema

Name	Required	Description	Default
`name`	No	Site name as shown by list_sites, e.g. my-portfolio. Provide name or siteId.
`siteId`	No	Site id from list_sites or get_site. Use instead of name.

Output Schema

Name	Required	Description
`url`	Yes
`name`	Yes
`plan`	Yes
`files`	Yes	Number of files the site serves now (live count). After a patch deploy it can exceed the last deploy's fileCount.
`siteId`	Yes
`status`	Yes	Lifecycle state. Sites are usable only in 'active'. 'deleted' is the soft-delete recovery bucket (returned until the team's restore window expires and the sweeper purges the row). 'deleting' is the transient state of an in-flight hard-delete request.
`history`	Yes
`bandwidth`	Yes
`filePaths`	No	Site-relative paths of every served file, to pick paths to read, patch or delete. Omitted when the pod cannot be inspected (e.g. not ready); `files` then falls back to the last deploy's fileCount.
`lastDeployAt`	Yes
`sourceStored`	Yes	Whether editable source is stored. Read and edit source, then build_and_deploy when true.
`customDomains`	Yes	Custom domains of this site and the team's custom-domain allowance; null when they could not be read.
`sourceManifest`	Yes	Saved source build settings. Preserve these when rebuilding.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

addedOutput schema / properties / customDomains

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "allowance": {
+          "description": "Custom domains the team's current plan includes.",
+          "type": "number"
+        },
+        "connected": {
+          "description": "Custom domains on this site from both sources, one entry per hostname.",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "domain": {
+                "description": "Hostname, e.g. shop.example.com.",
+                "type": "string"
+              },
+              "source": {
+                "description": "dashboard: linked on the dashboard Web Addresses page. mcp: added with add_custom_domain or the site API.",
+                "enum": [
+                  "dashboard",
+                  "mcp"
+                ],
+                "type": "string"
+              },
+              "status": {
+                "description": "live: verified and serving this site. pending: linked, not verified yet.",
+                "enum": [
+                  "live",
+                  "pending"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "domain",
+              "status",
+              "source"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "nextTool": {
+          "const": "add_custom_domain",
+          "description": "Present when this site has no custom domain yet and the team has room for one.",
+          "type": "string"
+        },
+        "used": {
+          "description": "Distinct custom domains in use across the team, both sources (same count as get_account).",
+          "type": "number"
+        }
+      },
+      "required": [
+        "connected",
+        "allowance",
+        "used"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Custom domains of this site and the team's custom-domain allowance; null when they could not be read."
+}

changedOutput schema / required

Previous value: -[
-  "siteId",
-  "name",
-  "url",
-  "plan",
-  "status",
-  "files",
-  "sourceStored",
-  "sourceManifest",
-  "lastDeployAt",
-  "bandwidth",
-  "history"
-]New value: +[
+  "siteId",
+  "name",
+  "url",
+  "plan",
+  "status",
+  "files",
+  "sourceStored",
+  "sourceManifest",
+  "lastDeployAt",
+  "bandwidth",
+  "history",
+  "customDomains"
+]

Changed5 schema fields changedOct 14, 2026

addedInput schema / properties / name / description

Added value: +"Site name as shown by list_sites, e.g. my-portfolio. Provide name or siteId."

addedInput schema / properties / siteId / description

Added value: +"Site id from list_sites or get_site. Use instead of name."

changedOutput schema / properties / bandwidth / properties / usedMb / description

Previous value: -"Outbound MB served by this site over the window (usage only — the bandwidth cap is team-scoped, see get_account)."New value: +"Outbound MB served by this site over the window (usage only; the bandwidth cap is team-scoped, see get_account)."

changedOutput schema / properties / filePaths / description

Previous value: -"Site-relative paths of every file currently on the pod (same scope as `files`). Lets a caller see what's there before deciding which paths to patch or delete, without having to download the site. Omitted when the live introspection step fails (e.g. pod not ready) — `files` then falls back to the most recent deploy's fileCount."New value: +"Site-relative paths of every served file, to pick paths to read, patch or delete. Omitted when the pod cannot be inspected (e.g. not ready); `files` then falls back to the last deploy's fileCount."

changedOutput schema / properties / files / description

Previous value: -"Number of files currently served by the site (live count from the pod, excluding lost+found and _staging). After update_site(mode:'patch'), this may be larger than the most recent deploy's fileCount because patch keeps the existing files. After update_site(mode:'replace'), it equals the most recent deploy's fileCount."New value: +"Number of files the site serves now (live count). After a patch deploy it can exceed the last deploy's fileCount."

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

Changed3 schema fields changedSep 5, 2026

addedOutput schema / properties / sourceManifest

Added value: +{
+  "anyOf": [
+    {},
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Saved source build settings. Preserve these when rebuilding."
+}

addedOutput schema / properties / sourceStored

Added value: +{
+  "description": "Whether editable source is stored. Read and edit source, then build_and_deploy when true.",
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "siteId",
-  "name",
-  "url",
-  "plan",
-  "status",
-  "files",
-  "lastDeployAt",
-  "bandwidth",
-  "history"
-]New value: +[
+  "siteId",
+  "name",
+  "url",
+  "plan",
+  "status",
+  "files",
+  "sourceStored",
+  "sourceManifest",
+  "lastDeployAt",
+  "bandwidth",
+  "history"
+]

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.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds the scope of the read (e.g. last 10 deploys rather than all deploys, whether editable source is stored), which is modest value beyond what annotations plus the output schema provide.

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?

Two sentences, front-loaded with purpose, then routing guidance. The enumeration of return fields is somewhat redundant given an output schema exists, which is the only real excess.

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?

For a simple read-only lookup with full schema coverage, no required params, and an output schema, the description covers purpose, alternatives, and content scope. It need not explain return values, and indeed the light redundancy there is the only gap.

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% and both parameters (name, siteId) are documented with sourcing hints and an either/or note. The description adds nothing about parameter syntax or precedence, so the baseline 3 applies – the schema does all the work here.

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 one site's details") and enumerates the payload (live URL, status, plan, source/build settings, domains, bandwidth, last 10 deploys). It also explicitly separates itself from list_sites and get_app_status, so the agent can distinguish it from siblings without reading schemas.

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 a concrete usage rule ("inspect a site before editing it") plus two named alternatives with the conditions that select them: list_sites for finding names, get_app_status for container services. Nothing about when to reach for this tool versus another is left to inference.

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.