Append one chunk of a single file to a staging session
add_file_chunkStream 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
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Target path inside the site root, e.g. 'portaal-admin.html'. Same path validation as add_files. | |
| isLast | Yes | True on the FINAL chunk. Triggers an assembled-size stat and refreshes session file count. Mid-stream chunks set false. | |
| content | Yes | This 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. | |
| isFirst | Yes | True on the FIRST chunk of a file. Truncates any existing scratch entry at this path and creates parent directories. Subsequent chunks must set false. | |
| deployId | Yes | Session id returned by begin_deploy. | |
| encoding | No | utf8 (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). | |
| expectedByteOffset | No | Optional 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
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| isLast | Yes | ||
| deployId | Yes | ||
| fileSize | No | Assembled file size on the pod after this chunk. Returned only when isLast=true so the caller can verify the concat succeeded. | |
| request_id | No | Server-assigned request correlation id. Quote it when contacting support. | |
| totalBytes | Yes | Session-wide cumulative bytes across all add_files / add_file_chunk calls. | |
| totalFiles | No | Session-wide file count after this chunk. Returned only when isLast=true. | |
| bytesWritten | Yes | Decoded bytes written by THIS chunk. | |
| remainingBudget | Yes | Bytes still available before hitting the 500 MB cap. |