VibeDeploy

Read a file from the editable source tree

read_source_file

Read-onlyIdempotent

Return one file from the site's editable source tree (the stored pre-build code), so any chat can edit the site without the original local files. list_source_files shows the paths. Use read_source_file for source; use read_file instead for the files the site serves.

Input Schema

Name	Required	Description
`name`	No	Site name as shown by list_sites, e.g. my-portfolio. Provide name or siteId.
`path`	Yes	Path inside the source tree, e.g. 'src/App.tsx'.
`siteId`	No	Site id from list_sites or get_site. Use instead of name.
`maxBytes`	No	Per-file size cap in bytes. Default 1048576, max 5242880.

Output Schema

Name	Required	Description	Default
`name`	Yes
`path`	Yes
`size`	Yes
`siteId`	Yes
`content`	Yes
`encoding`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 14, 2026

changedInput schema / properties / maxBytes / description

Previous value: -"Per-file size cap. Default 1048576, hard max 5242880."New value: +"Per-file size cap in bytes. Default 1048576, max 5242880."

addedInput schema / properties / name / description

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

changedInput schema / properties / path / description

Previous value: -"Site-relative path inside the source tree, e.g. 'src/App.tsx'."New value: +"Path inside the source tree, e.g. 'src/App.tsx'."

addedInput schema / properties / siteId / description

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

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

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and idempotence profile is fully covered by structured data. The description adds genuinely useful context about what the source tree is (pre-build code that lets a chat edit the site without local files), but says nothing about truncation behaviour for large files, the effect of the maxBytes cap, or error behaviour on a missing path.

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, zero waste, front-loaded with what is returned before the routing guidance. Each sentence earns its place: identity, path discovery, and alternative selection.

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?

An output schema exists, so return shape needn't be restated, and the annotations carry the safety profile. Combined with the explicit sibling routing and the path-source pointer, nothing an agent needs in order to call this correctly is missing.

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

Parameters4/5

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

Schema description coverage is 100% and all four parameters (name, path, siteId, maxBytes) carry their own descriptions including defaults and caps, so the schema does the heavy lifting. The description adds nothing parameter-specific beyond that, which is acceptable when coverage is this high, though a note that path must be a source-tree path from list_source_files would have been a small bonus.

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 file from the site's editable source tree'), and immediately clarifies what the source tree is ('the stored pre-build code'). It distinguishes itself from read_file explicitly and names list_source_files as the path source, so an agent can place it against the read_file/read_source_files/list_source_files cluster without opening any schema.

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 an explicit selection rule: 'Use read_source_file for source; use read_file instead for the files the site serves.' That is when-to-use, when-not-to-use and the named alternative in one sentence, plus a pointer to list_source_files for discovering valid paths.

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.