vibedeploy

Get site details

get_site

Read-onlyIdempotent

Return name, url, plan, last deploy time, and recent deploy history.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`siteId`	No

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes
`name`	Yes
`plan`	Yes
`files`	Yes	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.
`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 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.
`lastDeployAt`	Yes
`sourceStored`	Yes	Whether editable source is stored. Read and edit source, then build_and_deploy when true.
`sourceManifest`	Yes	Saved source build settings. Preserve these when rebuilding.

Schema Changelog

Changes observed during successful MCP inspections.

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

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific data returned, such as plan and deploy history, but no additional behavioral context like error handling, permissions, or rate limits. This meets the lower bar set by annotations but does not enrich behavior beyond return fields.

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?

One sentence with no filler, front-loading the action and the primary returned fields. It is appropriately sized for a simple getter.

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

Completeness2/5

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

The output schema and annotations cover return shape and safety, but the description leaves critical ambiguity: both input parameters are optional and there is no statement on how to select the site. It also fails to distinguish when this tool is appropriate compared to list_sites or get_site_analytics. For a tool with zero required parameters, this is a significant completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not explain either 'name' or 'siteId', nor how they relate (e.g., either/or or both). The only mention of 'name' refers to an output field, which could confuse the input parameter. No compensation is made for the missing schema descriptions.

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?

The description states the verb 'Return' and enumerates the exact fields (name, url, plan, last deploy time, recent deploy history), making the resource clear. It does not explicitly contrast with siblings like get_site_analytics or list_sites, but the listed fields distinguish it sufficiently.

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

Usage Guidelines2/5

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

No guidance is given on when to call get_site versus list_sites or get_site_analytics. It does not state whether to pass name, siteId, or both, nor any context for retrieving deploy history. The description is purely declarative.

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.