vibedeploy

List the editable source tree for a site

list_source_files

Read-onlyIdempotent

Return SHA-256 + size for every file in the site's editable source tree (the platform's copy of the pre-build code, not the served dist). Use BEFORE editing so you know which paths exist and which haven't changed since the last build. autoPromote:true will mirror the served dist into source for static-only sites whose source tree is empty (does nothing if the dist looks built).

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No
`siteId`	No
`autoPromote`	No	If true and the site has no source tree yet but its dist looks static, copy dist → source on the fly. Default: false.
`forcePromote`	No	If true, mirror dist → source EVEN when dist looks built (e.g. minified Vite output). Use when the original source isn't recoverable and you're willing to edit the build artefact directly. Sets manifest.noBuild=true automatically when no package.json is in the dist, so subsequent build_and_deploy short-circuits to a direct source→dist copy. forcePromote implies autoPromote.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`files`	Yes
`siteId`	Yes
`totalBytes`	Yes
`totalFiles`	Yes
`autoPromoted`	No	Set to true when this call ran the auto-promote (dist → source) before listing. Lets the caller learn the source tree was just synthesised from the served dist.

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

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

A3.5/5.0

Behavior1/5

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

This is an annotation contradiction. Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description states autoPromote/forcePromote can 'mirror the served dist into source' and 'copy dist → source,' which are mutating side effects. The description openly discloses mutating behavior while the annotations deny it, making the tool's safety profile unreliable.

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 with no filler: the first defines the return value and object, the second gives the workflow, and the third explains the only surprising parameter behavior. Information is front-loaded and each sentence earns its place.

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

Completeness3/5

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

The output schema covers return values and the schema covers forcePromote details, so the description doesn't need to repeat everything. However, the readOnlyHint contradiction is a serious completeness gap, and the description omits forcePromote's implications even though that parameter can overwrite source and change subsequent build behavior.

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 50%, and the description adds useful context for autoPromote but largely restates or pre-empts the schema text. name and siteId are left undocumented, and forcePromote is not mentioned in the description despite being a subtle, mutating parameter whose schema description carries important caveats.

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?

The description states a specific verb and resource: it 'Return[s] SHA-256 + size for every file in the site's editable source tree' and immediately distinguishes that tree from 'the served dist'. This is clear enough for an agent to differentiate it from siblings like list_file_hashes or read_source_files.

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

Usage Guidelines4/5

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

The description gives explicit usage context: 'Use BEFORE editing so you know which paths exist and which haven't changed since the last build.' It also explains when autoPromote is relevant. It doesn't name alternatives or exclusions, but the primary workflow guidance is clear.

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.