Skip to main content
Glama

VibeDeploy

by be.vibedeploy
OverviewDiscussionsAdmin

Read a file from a deployed site

read_file
Read-onlyIdempotent

Return one file the site serves now, as text (utf8) or base64 for binary files, e.g. to edit it and send it back with update_site mode:'patch'. Use read_file for the served files; use read_source_file instead for the editable source tree (get_site.sourceStored). Max 5242880 bytes; get_site.filePaths lists the paths.

Input Schema

NameRequiredDescriptionDefault
nameNoSite name as shown by list_sites, e.g. my-portfolio. Provide name or siteId.
pathYesSite-relative path of the file to read (e.g. 'index.html', 'assets/main.css'). No leading slash, no '..'.
siteIdNoSite id from list_sites or get_site. Use instead of name.
maxBytesNoPer-file size cap in bytes. Default 1048576, max 5242880. A larger file fails with FILE_TOO_LARGE instead of returning truncated bytes.

Output Schema

NameRequiredDescriptionDefault
nameYes
pathYesEchoes the input path, normalized (leading slash stripped, backslashes converted).
sizeYesSize in bytes of the file on the pod.
siteIdYes
contentYes
encodingYesutf8: `content` is the text. base64: the file is binary (image, font, ...) and `content` is base64; decode before use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / maxBytes / description
      Previous value: -"Per-file size cap. Default 1048576, hard max 5242880. If the file is larger, the call fails with FILE_TOO_LARGE rather than returning truncated bytes — splitting source mid-token would corrupt downstream edits."New value: +"Per-file size cap in bytes. Default 1048576, max 5242880. A larger file fails with FILE_TOO_LARGE instead of returning truncated bytes."
    • changedInput schema / properties / name / description
      Previous value: -"Site name (subdomain) or custom domain. Same lookup rules as get_site."New value: +"Site name as shown by list_sites, e.g. my-portfolio. Provide name or siteId."
    • changedInput schema / properties / siteId / description
      Previous value: -"Alternative to name. One of name|siteId is required."New value: +"Site id from list_sites or get_site. Use instead of name."
    • changedOutput schema / properties / encoding / description
      Previous value: -"How to interpret `content`. utf8 means the file is text and `content` is the raw text. base64 means the file is binary (image/font/etc.) and `content` is base64 — decode before use."New value: +"utf8: `content` is the text. base64: the file is binary (image, font, ...) and `content` is base64; decode before use."
  2. Changed1 schema field changed
    • removedOutput schema / properties / request_id
      Removed value: -{
-  "description": "Server-assigned request correlation id. Quote it when contacting support.",
-  "type": "string"
-}
  3. Changed1 schema field changed
    • addedOutput schema / properties / request_id
      Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description still adds real behavior beyond that: dual text/base64 encoding, a hard 5242880-byte ceiling, and the fact that oversized files fail with FILE_TOO_LARGE rather than returning truncated bytes. Auth requirements and pagination are unstated, keeping it short of a 5.

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 dense sentences: purpose first, routing second, limits and path discovery third. No filler and no repetition of structured fields; every clause carries a distinct constraint.

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-format detail is unnecessary, and annotations carry the safety semantics. Combined with the size cap, error behavior, sibling routing, and path source, an agent has everything needed to call this correctly.

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 coverage is 100%, so the baseline is 3, and the schema already documents name/siteId/path/maxBytes well. The description adds value the schema does not: that maxBytes is an error threshold rather than a truncation control, and that valid paths come from get_site.filePaths.

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 the site serves now') plus the encoding contract (utf8 text or base64 for binary). It explicitly distinguishes itself from read_source_file, so an agent can separate the two without opening either 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 routing rule: 'Use read_file for the served files; use read_source_file instead for the editable source tree (get_site.sourceStored).' It also names the downstream follow-up (update_site mode:'patch') and the discovery path (get_site.filePaths), so both when-to-use and alternatives 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 toolsInspect
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.

Resources