Skip to main content
Glama

SnapHost

by ai.snaphost
OverviewDiscussionsAdmin

Create bundle upload

create_bundle_upload

Start a bundle upload for a site too big to inline (a multi-file or media-heavy app, e.g. a built React site), or for a single file (Markdown, a notebook, a PDF, a .docx, .pptx or .xlsx, an image, a video, an audio, a CSV, a Mermaid diagram or a text file, sent as it is under its filename, given here once). Returns an upload_id to send the bytes against, then publish_site or update_site with that upload_id instead of html/zipBase64. Two ways to send it. Send it with upload_bundle_part, one numbered part per call: that is a tool call on this connection, so it works from any client that can call this tool at all, including a sandbox with no network of its own. Or PUT the .zip to upload_url (HTTP PUT, Content-Type application/zip; above max_part_bytes, to upload_url/parts/0, /parts/1, ... in order), which is fewer, larger requests when your shell can reach that host; storage_url is the same PUT straight to the storage host, one request at any size. Your tool calls and your shell do not share a network: a PUT that is refused (a 403 naming the host, or a connection that never leaves) says nothing about upload_bundle_part, so switch to it rather than asking the owner to change any network settings. The upload is single-use and expires; request a new one if it lapses. It belongs to the workspace this call acts in: pass the same workspace_id to every upload_bundle_part and to the publish.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filenameNoThe single file's own name with its extension (`report.pdf`, `talk.mp4`), when the upload is one non-zip file rather than a .zip. The upload then remembers it: the parts and the publish need not repeat it. Omit for a .zip.
workspace_idNoOptional: the workspace to act in, from list_workspaces (the connection reaches the person's personal space and every workspace they are a member of). Required on a write when the connection reaches more than one workspace. Omit to act in the personal space (for an older single-workspace connection, the one workspace it was authorized for).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / filename
      Added value: +{
+  "description": "The single file's own name with its extension (`report.pdf`, `talk.mp4`), when the upload is one non-zip file rather than a .zip. The upload then remembers it: the parts and the publish need not repeat it. Omit for a .zip.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Optional: the workspace (the personal space or a Pro workspace) to act in, from list_workspaces. Omit to act in the token owner's own account."New value: +"Optional: the workspace to act in, from list_workspaces (the connection reaches the person's personal space and every workspace they are a member of). Required on a write when the connection reaches more than one workspace. Omit to act in the personal space (for an older single-workspace connection, the one workspace it was authorized for)."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give the non-destructive, non-idempotent, non-open-world profile. The description adds the traits an agent actually needs: the upload is single-use and expires, it is bound to the workspace the call acts in, the same workspace_id must be reused for every part and the publish, and the tool-call network is isolated from the shell's network.

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?

Purpose and the two transports are front-loaded and every sentence carries real information, but the prose is dense and parenthesis-heavy (~250 words for a session-creation call), which makes it harder to scan than it needs to 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?

No output schema exists, yet the description names what comes back (upload_id, upload_url, storage_url, max_part_bytes) and how each is consumed, plus expiry and workspace-binding caveats. An agent has everything needed to call this correctly and follow up.

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 nonetheless adds operational meaning: filename is given once and remembered across parts and publish, and workspace_id must be passed identically to every upload_bundle_part and to the publish. Some of this restates the schema, but the cross-call consistency requirement is new.

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?

Specific verb+resource ("Start a bundle upload") with the exact scope of what qualifies (multi-file/media-heavy site, or one non-zip file by type). It explicitly distinguishes itself from siblings: publish_site/update_site consume the returned upload_id, and upload_bundle_part is named as the alternative transport.

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?

Explicit when-to-use: instead of inline html/zipBase64. Explicit branch conditions between the two transports (upload_bundle_part for any client incl. sandboxes with no network; HTTP PUT when the shell can reach the host; storage_url for one request at any size). It even gives the failure-handling rule (a 403 on PUT says nothing about upload_bundle_part, so switch rather than changing network settings).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SnapHost toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources