VibeDeploy

Read multiple source files in one call

read_source_files

Read-onlyIdempotent

Read up to 50 files from the editable source tree in one call (8388608 bytes in total). Each path succeeds or fails on its own; paths past the budget fail with BATCH_BUDGET_EXCEEDED. Use read_source_files for source; use read_files 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.
`paths`	Yes	Paths inside the source tree, e.g. 'src/App.tsx' (1 to 50). Results keep this order.
`siteId`	No	Site id from list_sites or get_site. Use instead of name.
`maxBytesPerFile`	No	Per-file size cap in bytes. Default 1048576, max 5242880.

Output Schema

Name	Required	Description	Default
`name`	Yes
`files`	Yes
`siteId`	Yes
`totalBytes`	Yes
`budgetExceededAt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 14, 2026

addedInput schema / properties / maxBytesPerFile / description

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

addedInput schema / properties / paths / description

Added value: +"Paths inside the source tree, e.g. 'src/App.tsx' (1 to 50). Results keep this order."

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

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds meaningful behavior: per-path independent success/failure, the BATCH_BUDGET_EXCEEDED failure mode, and the 8388608-byte total budget. This is exactly the kind of partial-failure semantics an agent needs before batching.

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, front-loaded with the batch scope and sizing, then behavioral failure semantics, then the sibling routing. No filler and every sentence carries distinct information.

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-value explanation is unnecessary; the description covers scope, budget limits, failure behavior, and alternative selection. Nothing needed to invoke this tool 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 coverage is 100%, so the baseline is 3; the description earns above that by disclosing the total batch byte budget (8388608) that is not present in the schema and by framing paths as order-preserving with independent outcomes. Per-file cap and path count are already in the schema, so no additional credit there.

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 (Read), resource (source tree files), and batch scope (up to 50 files in one call). It is clearly distinguishable from the singular sibling read_source_file and from read_files, which the description names explicitly.

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?

Explicitly routes the agent: 'Use read_source_files for source; use read_files instead for the files the site serves.' The when-to-use-this vs. when-to-use-alternative decision is fully stated with no inference required.

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.