VibeDeploy

List the editable source tree for a site

list_source_files

Read-onlyIdempotent

List path, SHA-256 and size of every file in the site's editable source tree (the stored pre-build code, not the served files). Read-only. A site without a source tree returns SOURCE_NOT_STORED: write the source with write_source_files, or copy plain static served files with promote_dist_to_source.

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.
`autoPromote`	No	Deprecated and ignored. Use promote_dist_to_source with mode 'auto'.
`forcePromote`	No	Deprecated and ignored. Use promote_dist_to_source with mode 'force'.

Output Schema

Name	Required	Description
`hint`	No	Set when the deprecated autoPromote or forcePromote flag was passed.
`name`	Yes
`files`	Yes
`siteId`	Yes
`totalBytes`	Yes
`totalFiles`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 14, 2026

changedInput schema / properties / autoPromote / description

Previous value: -"If true and the site has no source tree yet but its dist looks static, copy dist → source on the fly. Default: false."New value: +"Deprecated and ignored. Use promote_dist_to_source with mode 'auto'."

changedInput schema / properties / forcePromote / description

Previous value: -"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."New value: +"Deprecated and ignored. Use promote_dist_to_source with mode 'force'."

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

removedOutput schema / properties / autoPromoted

Removed value: -{
-  "description": "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.",
-  "type": "boolean"
-}

addedOutput schema / properties / hint

Added value: +{
+  "description": "Set when the deprecated autoPromote or forcePromote flag was passed.",
+  "type": "string"
+}

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

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that: the exact returned fields (path/SHA-256/size) and the specific error code plus recovery path when no source tree exists.

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 short sentences: purpose and scope first, the read-only note, then the error/recovery path. Every sentence earns its place and nothing is buried.

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?

With an output schema present, return values need no further explanation, and the description still covers scope, safety, and the failure mode with recovery alternatives. Nothing an agent needs to invoke it correctly is missing.

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 the deprecated autoPromote/forcePromote flags are fully documented in the schema. The description adds no parameter-level meaning beyond that, making the high-coverage baseline of 3 appropriate.

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 gives a specific verb (List) plus the exact returned fields (path, SHA-256, size) and scopes the resource to the 'editable source tree', explicitly distinguishing it from served files. It does not, however, differentiate itself from the sibling list_file_hashes, leaving a small ambiguity an agent must resolve.

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?

It names the failure condition (SOURCE_NOT_STORED) and routes the agent to alternatives (write_source_files, promote_dist_to_source), which is genuine when-to/alternative guidance. It stops short of an explicit 'use this rather than list_file_hashes/read_source_files' rule.

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.