Skip to main content
Glama

vibedeploy

by be.vibedeploy

Append one chunk of a single file to a staging session

add_file_chunk

Stream a single file across multiple calls when its content exceeds the per-MCP-call output budget. LAST RESORT — try these first: (1) add_files with encoding:'gzip+base64' fits ~250 KB of text source in ONE call (gzip locally, base64, send — no chunking, no ordering hazards); (2) begin_deploy's uploadUrl takes a 100 MB tarball in one HTTP POST if your sandbox can reach mcp.vibedeploy.be; (3) deploy_from_url if the files are fetchable from a public URL. Only chunk when none of those work. When you DO chunk, gzip+base64 each chunk too — it quadruples the source bytes per chunk. Mark the first chunk with isFirst=true (truncates + mkdir) and the last with isLast=true (returns assembled size). Send chunks for the same path serially — concurrent chunks interleave and corrupt the file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesTarget path inside the site root, e.g. 'portaal-admin.html'. Same path validation as add_files.
isLastYesTrue on the FINAL chunk. Triggers an assembled-size stat and refreshes session file count. Mid-stream chunks set false.
contentYesThis chunk's bytes. Either raw UTF-8 (default) or base64-encoded — set encoding accordingly. PRACTICAL CHUNK SIZE: bounded by your LLM client's tool-output token budget, NOT by VibeDeploy's server. Empirically ~80 KB of base64 (≈60 KB raw bytes) per chunk is the safe upper bound for current Claude / GPT clients before tool output gets truncated. The server itself accepts up to 100 MB per call (Caddy cap) and 500 MB cumulative across the session. If you keep hitting truncation: split into smaller chunks, OR sidestep tool-output entirely via `deploy_from_url` (publish a tarball to github raw / gist / S3 → 1 tool call) or POST to begin_deploy's uploadUrl from your code-execution sandbox if it can reach mcp.vibedeploy.be.
isFirstYesTrue on the FIRST chunk of a file. Truncates any existing scratch entry at this path and creates parent directories. Subsequent chunks must set false.
deployIdYesSession id returned by begin_deploy.
encodingNoutf8 (default), base64 (binary files), or gzip+base64 (compress this chunk's bytes locally first; server gunzips before append). Encoding is per-chunk — you can mix across chunks of the same file (e.g. gzip+base64 for big text chunks, base64 for binary tail).
expectedByteOffsetNoOptional alignment check. The byte offset where THIS chunk should start in the assembled file: 0 for isFirst, otherwise the sum of all prior chunks' decoded bytes for this path. If the server's actual offset disagrees, the call fails with MISALIGNED_CHUNK before any bytes are written — catches the classic 'split base64 on a 4-char boundary that wasn't a byte boundary' bug. Omit to skip the check.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
isLastYes
deployIdYes
fileSizeNoAssembled file size on the pod after this chunk. Returned only when isLast=true so the caller can verify the concat succeeded.
request_idNoServer-assigned request correlation id. Quote it when contacting support.
totalBytesYesSession-wide cumulative bytes across all add_files / add_file_chunk calls.
totalFilesNoSession-wide file count after this chunk. Returned only when isLast=true.
bytesWrittenYesDecoded bytes written by THIS chunk.
remainingBudgetYesBytes still available before hitting the 500 MB cap.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedOutput schema / properties / request_id
      Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Discloses that isFirst truncates and creates directories, isLast returns assembled size, and concurrent chunks corrupt the file. Provides practical chunk size guidance and server limits. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with problem, alternatives, then detailed procedure. Slightly long but every sentence is informative.

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

Completeness4/5

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

Provides complete guidance for a complex streaming tool, covering usage, behavior, parameters, and limits. Output schema exists (not shown) so return values need no explanation.

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%, but description adds practical advice (e.g., chunk size bounds, encoding per-chunk, alignment check) that goes beyond the schema.

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 clearly states the tool streams a single file across multiple calls when content exceeds the per-MCP-call output budget. It distinguishes from siblings like add_files, deploy_from_url, and begin_deploy by framing itself as a last resort.

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 lists three alternatives with reasoning and says 'Only chunk when none of those work.' Also advises sending chunks serially to avoid corruption.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target a distinct resource and action—deploy, file, domain, snapshot, form, analytics—and the descriptions carefully clarify overlap (e.g., deploy_site vs update_site vs begin_deploy). A few pairs like read_file/read_source_file or list_file_hashes/list_source_files could be confused, but the pattern is clear enough to avoid misselection.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern (add_, list_, get_, read_, update_, delete_, verify_, etc.), with singular verbs for single resources and plural verbs for batches. This makes the surface highly predictable.

Tool Count2/5

39 tools is well beyond the typical well-scoped surface and many could be consolidated (e.g., read_file/read_files/read_source_file/read_source_files, or the multiple deploy entry points). The broad domain explains some of the count, but the set feels bloated and will slow tool selection.

Completeness3/5

The core deploy lifecycle is well covered: create/read/update/delete sites, patch files, manage custom domains, and configure forms. However, there are notable gaps—snapshots can be created and listed but not restored or deleted, and there is no explicit rollback-to-previous-deploy mechanism, which are common expectations for a deployment platform.

Resources