VibeDeploy

Delete a site (restorable until purged)

delete_site

DestructiveIdempotent

Soft-delete a site (confirm:true required). It stops serving at once and is purged after the plan's restore window (purgesAt in the result); until then the user can restore it in the VibeDeploy dashboard. Use delete_site to remove the whole site; use remove_app instead to stop only its container services.

Input Schema

Name	Required	Description
`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.
`confirm`	Yes	Must be exactly true to actually delete the site.

Output Schema

Name	Required	Description
`name`	Yes
`siteId`	Yes
`status`	Yes
`accepted`	Yes
`purgesAt`	Yes	ISO time the site is purged for good: the end of the plan's restore window. Until then it can be restored in the VibeDeploy dashboard.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 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 / purgesAt / description

Previous value: -"ISO timestamp when the soft-delete becomes a hard purge (~7 days from now)."New value: +"ISO time the site is purged for good: the end of the plan's restore window. Until then it can be restored in the VibeDeploy dashboard."

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

Behavior5/5

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

Goes well beyond the annotations: it discloses that deletion is soft/reversible, that serving stops immediately, that purging happens after the plan's restore window, that purgesAt appears in the result, and where restoration happens (dashboard). The destructiveHint and idempotentHint annotations only signal the safety profile; the description supplies the actual lifecycle semantics.

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, each load-bearing: constraint first, then lifecycle/restore behavior, then sibling routing. No filler, and the most decision-relevant facts are front-loaded.

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 destructive 3-param tool with an output schema present, the description covers the safety profile, reversibility, timing, and sibling selection; return values need not be explained since purgesAt is referenced contextually and the output schema carries the rest.

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 name, siteId and confirm are already fully documented in the schema, and the description's 'confirm:true required' merely restates it. No additional syntax, format or interaction detail about the identity parameters is added, so 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?

Opens with a specific verb+resource+key constraint ('Soft-delete a site (confirm:true required)') and explicitly contrasts with the sibling remove_app, so an agent can distinguish it without opening either schema. The scope of destruction (whole site vs. container services) is unambiguous.

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?

States the required precondition (confirm:true) and names the alternative tool with the condition that selects it: 'Use delete_site to remove the whole site; use remove_app instead to stop only its container services.' Both when-to-use and when-to-use-something-else are covered.

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.