VibeDeploy

Append one chunk of a single file to a staging session

add_file_chunk

Send one file in several calls when it is too big for a single tool call. Last resort: first try add_files with encoding:'gzip+base64' (about 250 KB of text in one call), begin_deploy's uploadUrl (one 100 MB tar POST) or deploy_from_url (public archive URL). When chunking, gzip+base64 each chunk too, mark the first with isFirst and the last with isLast, and send chunks of one file one after another: parallel chunks corrupt it. After a transport error, do not resend the chunk blindly: restart the file from its first chunk (isFirst truncates it).

Input Schema

Name	Required	Description
`path`	Yes	Path relative to the site root, e.g. 'portaal-admin.html'. Same rules as add_files.
`isLast`	Yes	True on the final chunk: returns the assembled file size and refreshes the session file count.
`content`	Yes	This chunk's bytes, as UTF-8 text or encoded per encoding. Chunk size is limited by your client's tool-output budget, not by the server: about 80 KB of base64 (60 KB raw) per chunk is a safe upper bound.
`isFirst`	Yes	True on the first chunk of a file: truncates any staged file at this path and creates parent directories.
`deployId`	Yes	Session id returned by begin_deploy.
`encoding`	No	utf8 (default), base64 (binary), or gzip+base64 (gzip this chunk locally; the server gunzips before appending). Set per chunk.
`expectedByteOffset`	No	Optional check: where this chunk starts in the assembled file (0 for the first chunk, else the decoded bytes sent so far). A mismatch fails with MISALIGNED_CHUNK before writing, which catches base64 split mid-byte.

Output Schema

Name	Required	Description
`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.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 14, 2026

changedInput schema / properties / content / description

Previous value: -"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."New value: +"This chunk's bytes, as UTF-8 text or encoded per encoding. Chunk size is limited by your client's tool-output budget, not by the server: about 80 KB of base64 (60 KB raw) per chunk is a safe upper bound."

changedInput schema / properties / encoding / description

Previous value: -"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)."New value: +"utf8 (default), base64 (binary), or gzip+base64 (gzip this chunk locally; the server gunzips before appending). Set per chunk."

changedInput schema / properties / expectedByteOffset / description

Previous value: -"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."New value: +"Optional check: where this chunk starts in the assembled file (0 for the first chunk, else the decoded bytes sent so far). A mismatch fails with MISALIGNED_CHUNK before writing, which catches base64 split mid-byte."

changedInput schema / properties / isFirst / description

Previous value: -"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."New value: +"True on the first chunk of a file: truncates any staged file at this path and creates parent directories."

changedInput schema / properties / isLast / description

Previous value: -"True on the FINAL chunk. Triggers an assembled-size stat and refreshes session file count. Mid-stream chunks set false."New value: +"True on the final chunk: returns the assembled file size and refreshes the session file count."

changedInput schema / properties / path / description

Previous value: -"Target path inside the site root, e.g. 'portaal-admin.html'. Same path validation as add_files."New value: +"Path relative to the site root, e.g. 'portaal-admin.html'. Same rules as add_files."

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

Behavior5/5

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

Annotations only give the generic safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds operationally critical behavior the annotations cannot convey: chunks of one file must be sent serially because 'parallel chunks corrupt it', isFirst truncates an existing staged file, and after a transport error the file must be restarted from its first chunk rather than blindly resent.

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?

The opening sentence front-loads the use case and the alternatives follow in priority order, so nothing is buried. It is a single dense paragraph with several clause-chained rules, which is efficient but slightly harder to scan than a structured list would be.

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?

This is a complex stateful chunked-upload protocol with 7 parameters, and the description covers the sequencing rule, the encoding requirement, the boundary flags, and the failure-recovery procedure. An output schema exists, so return values need not be restated, and nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter including isFirst, isLast, encoding and expectedByteOffset is already fully documented in the schema; the baseline of 3 applies. The description reinforces the ordering semantics of isFirst/isLast in a workflow context, but adds little parameter detail the schema does not already carry.

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 with its scope: 'Send one file in several calls when it is too big for a single tool call.' It goes further and names the sibling tools it exists to avoid (add_files, begin_deploy's uploadUrl, deploy_from_url), so an agent can distinguish it from them 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?

Explicitly frames itself as a last resort and gives the ordered alternatives with their capacity limits ('add_files with encoding:gzip+base64 (about 250 KB)', 'uploadUrl (one 100 MB tar POST)', 'deploy_from_url'). The when-to-use and when-not-to-use conditions are both present and unambiguous.

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.