Skip to main content
Glama
Sign In

SnapHost

by ai.snaphost
OverviewDiscussionsAdmin

Create bundle upload

create_bundle_upload

Start a bundle upload for bytes that html or files cannot carry: a site with images, fonts or other binaries (a built React site), or a single binary file (a PDF, a .docx, .pptx or .xlsx, an image, a video, an audio), sent as it is under its filename, given here once. Text (a page and its CSS or JS, a Markdown, CSV, Mermaid, notebook or code file) goes as html or files instead and needs no upload. Returns an upload_id to send the bytes against, then publish_site or update_site with that upload_id instead of html/files/zipBase64. Sending the bytes needs a shell that makes the SnapHost tool calls itself. A shell here is a coding agent in a terminal (Claude Code, Cursor, Codex CLI); a chat app's code sandbox does not count, since its output would have to be retyped into the call. Without a shell, do not open an upload and do not build base64. Ask the person to drop the file (downloaded from the chat if it lives there; a .zip of the built folder with index.html at its root for an app) on the dashboard, after switching the dashboard to the workspace you name: the drive (https://app.snaphost.ai/) for a new site, or the site's own page (https://app.snaphost.ai/sites/<site_id>, "Upload a new version") to keep an existing link; the site_id comes from list_sites or the publish result. Then list_sites shows it (a new site is the newest, named after the file) and every sharing tool applies. With a shell, two ways to send it. Send it with upload_bundle_part, one numbered part per call: a tool call on this connection, so it works even 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 with no body limit, up to the bundle cap. 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

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.7/5.0
Behavior5/5

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

Annotations only declare it is a non-readonly, non-destructive, non-idempotent write; the description adds the operational facts an agent actually needs: the upload is single-use and expires, it is workspace-scoped and the same `workspace_id` must be reused across parts and the publish, the return value is an `upload_id` consumed by publish_site/update_site, and that tool calls and the shell do not share a network. No statement conflicts with the annotations (single-use/expiring is consistent with idempotentHint=false).

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

Conciseness3/5

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

Purpose is front-loaded and most sentences carry load-bearing operational detail, but the body is a dense wall of run-on sentences mixing selection criteria, HTTP mechanics, dashboard URLs, and human-fallback instructions. The no-shell dashboard procedure (with full URLs and "Upload a new version" quoting) is long for a section that mostly tells the agent to stop and ask a person, and it dilutes the core call-and-then-publish path.

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?

For a two-parameter tool with no output schema, this covers everything an agent needs: what content qualifies, what gets returned, which tools consume the result, both byte-transfer mechanisms with their limits (`max_part_bytes`, bundle cap), the expiry/single-use lifecycle, and the workspace-consistency requirement. Nothing material is left to inference for a correct invocation.

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, but the description adds real meaning: `filename` is "given here once" because the upload remembers it, so parts and publish need not repeat it, and `workspace_id` must be echoed on every upload_bundle_part and the publish call. That cross-tool propagation rule is not derivable from the schema alone.

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?

Opens with a concrete verb+resource ("Start a bundle upload") and immediately bounds scope to bytes that `html` or `files` cannot carry, enumerating the qualifying cases (built site with binaries, single PDF/docx/pptx/xlsx/image/video/audio) and the disqualifying ones (text, CSS/JS, Markdown, CSV, code). It also names the sibling handoffs (upload_bundle_part, publish_site, update_site) so an agent can place it in the workflow without opening a 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?

Explicit when-to-use (binary content), when-not-to-use (anything textual belongs in `html`/`files`; without a shell, do not open an upload and do not build base64), and concrete alternatives with selection criteria: upload_bundle_part for no-network shells, PUT to `upload_url` for fewer larger requests, `storage_url` when a single unbounded request is needed. It even tells the agent what failure signals (403 naming the host, a request that never leaves) do NOT mean, and to fall back rather than renegotiate 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