Skip to main content
Glama

upload

Destructive

File upload: stream-upload (one-shot — auto-finalizes, no filesize needed), chunked (create-session → chunk → finalize, for files over the 100 MB blob cap), web URL import, and batch (many small files). Call action='describe' for the full action/param reference. Side effects: finalize/stream/stream-upload/web-import/batch create files and consume storage credits. Same-name uploads to a folder OVERWRITE the existing node in place (preserved as a recoverable version). BYTES → SERVER: the DEFAULT for every file/binary is the POST /blob sidecar — a plain HTTP POST outside the MCP pipe (the create-session/blob-info response hands you a ready-to-run curl command) carrying RAW BYTES — no base64 inflation, no MCP size limit, up to 100 MB. stream-upload forwards them to the platform as a raw octet stream; chunk and batch send them as multipart. Either way the bytes never pass through base64. It returns a blob_id you pass to stream-upload/chunk/batch. ⚠️ content_base64 is a LAST RESORT, NOT a peer option — ~33% inflation plus a few-MB MCP transport cap means it FAILS for all but the smallest files. If you cannot reach POST /blob, that is almost always a CLIENT-SIDE FIREWALL/PROXY/EGRESS restriction: tell the user to allow the /blob endpoint rather than degrading to base64. content is for text you are composing ON THE FLY through the MCP (verbatim UTF-8) — not a file-upload fallback. UPLOAD STRATEGY (read top-to-bottom, pick the FIRST that matches): (1) Have a URL? → web-import (single call). (2) EVERYTHING ELSE up to 100 MB → POST /blob, then stream-upload with blob_id (single call, auto-finalizes, NO filesize required). Use this EVEN WHEN THE EXACT BYTE COUNT IS KNOWN — knowing the size does not make the chunked path better, it only makes it possible, and it costs 3+ round-trips plus the 10522 mismatch trap. If /blob seems unreachable, CHECK FIREWALL/SECURITY SETTINGS FIRST — falling back to content_base64 will fail for anything but a tiny file. (3) Over the 100 MB blob cap (must split across several blobs), or you need the session id between calls → create-session + chunk(blob_id) + finalize. filesize must match the bytes you actually upload — mismatch causes finalize to fail with code 10522 and you must cancel the session. (4) Multiple small files (≤4 MB each, ≤200 total) into one folder? → batch. Use blob_id (POST /blob) for every file/binary upload. If /blob is unreachable, raise the client-side firewall/proxy restriction with the user — content_base64 is a last resort that fails above a few MB, not a substitute. Do NOT guess filesize for generated content — use stream-upload. max_size is a hard ceiling that aborts mid-transfer — always overestimate or omit (server uses plan limit).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orgNoOrg ID for limit resolution.
urlNoSource URL to import from.
hashNoFile hash for verification.
planNoOverride billing plan to check (e.g. free, pro).
waitNoLong-poll wait in SECONDS, 1-590 (NOT milliseconds; 0/omitted returns immediately). The server holds the connection until the upload reaches a terminal status. Sending a millisecond value here would hold for minutes and blow past the tool-call timeout.
filesNoBatch manifest (1..200 entries). Each: filename + one of blob_id/content/content_base64.
limitNoMax results (1-100, default 50).
actionYesOperation. Use 'describe' for full action reference.
offsetNoPagination offset.
statusNoFilter by status.
streamNoStream mode — size optional, single POST, auto-finalizes.
blob_idNoBlob ID from POST /blob — the **default source** for all file & binary uploads (no base64, no MCP size limit, up to 100 MB). Single-use.
contentNo**Text only** — stored verbatim UTF-8. This is for writing content you are composing **on the fly** directly through the MCP (a note, a generated report, a snippet you just produced) — NOT a fallback for uploading an existing file. Do NOT pass base64 here (use content_base64). One of content/content_base64/blob_id.
creatorNoClient identifier echoed back (alphanumeric + hyphens).
file_idNoFile ID for update context.
blob_refNoAlias for blob_id (deprecated). Accepted on chunk/stream/stream-upload only.
chunk_idNoSpecific chunk number (omit for all).
filenameNoFile name. Optional when target_node_id is set (auto-resolved); pass to rename-on-replace.
filesizeNoTotal file size in bytes.
max_sizeNoStream-body byte ceiling — aborts mid-transfer if exceeded. Always overestimate; omit to use plan limit. Stream sessions only.
passwordNoFile Share link password (profile_type=fileshare only). Forwarded ONLY as the x-ve-password header on every upload phase — never in a URL/log. Supply when the target share is password-protected.
share_idNoAlias for profile_id when the profile is a share — implies profile_type=share (so profile_type may be omitted).
folder_idNoTarget folder OpaqueId or "root". Omit for instance root.
hash_algoNoHash algorithm (e.g. 'sha256').
upload_idNoUpload session ID or web upload job ID.
chunk_sizeNoChunk size in bytes (server picks default).
context_idNoAlias for profile_id (either name works)
profile_idNoPolymorphic context ID (pair with profile_type=workspace|share|fileshare). Typed aliases let you omit profile_type: workspace_id (⇒ workspace) / share_id (⇒ share); also context_id / instance_id. Target workspace/share ID, or the File Share id for a fileshare write-back. fileshare has NO typed alias — pass profile_type=fileshare explicitly.
instance_idNoTarget workspace/share ID — also the profile_id alias for upload flows; profile_id is canonical.
chunk_numberNo1-indexed chunk number.
context_typeNoAlias for profile_type (either name works).
include_hashNoCompute SHA-256 client-side for entries without a hash (default true when omitted).
profile_typeNoTarget type: workspace | share | fileshare (alias: context_type). Use `fileshare` ONLY for content write-back to a File Share's bound file (requires target_node_id = the bound node id from `fileshare details`; create-style new-file flows are rejected for fileshare).
workspace_idNoAlias for profile_id when the profile is a workspace — implies profile_type=workspace (so profile_type may be omitted).
if_version_idNoCompare-and-swap base for an overwrite. Enforced on EVERY update target — workspace, share and File Share. Pass the version id your edit was based on; record it on create-session/stream-upload (finalize does NOT read it). On a stale base the session ends assembly_failed with CONFLICT_VERSION_MISMATCH:<id> — rebase and retry. Omitting it is last-write-wins. See action=describe.
action_contextNoContext: create or update.
content_base64NoBase64-encoded **binary**, server-decoded. ⚠️ **LAST RESORT — expect FAILURE above a few MB** (~33% inflation + MCP transport cap). If POST /blob is unreachable that is almost always a CLIENT-SIDE FIREWALL/PROXY restriction, not a server limit — have the user allow /blob instead of falling back here. Use `blob_id` for any real file.
parent_node_idNoParent folder OpaqueId or "root". On create-session, stream-upload, and web-import, folder_id is accepted as an alias (either name works).
target_node_idNoOverwrite this specific node (preserves node_id; new version). When set, parent_node_id is ignored and filename is optional (auto-resolved). Must be a file node. REQUIRED for profile_type=fileshare write-back — set it to the File Share's bound node id (from `fileshare details` → fileshare.file.id).
describe_actionNoWhen action='describe', narrow the output to ONE action's full params/notes (e.g. 'chunk'). Omit to get the compact action index.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=true, but the description adds substantial behavioral context: overwriting same-name uploads in place while preserving a recoverable version, consuming storage credits on certain actions, the 10522 filesize mismatch failure, max_size aborting mid-transfer, wait being in seconds, and password being sent only as a header. This goes far beyond what annotations reveal and matches the destructiveHint of overwrites and credit consumption.

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

Conciseness2/5

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

The description is very long and contains notable redundancy: the content_base64-is-a-last-resort and firewall advice is repeated multiple times, and the 'no base64, no MCP size limit, up to 100 MB' claim appears more than once. Although the UPLOAD STRATEGY section is well-structured and front-loaded, the overall block is far from concise, and some sentences restate earlier warnings.

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 tool with 40 parameters, 20 actions, and no output schema, this description is remarkably complete: it covers the full decision tree, side effects, failure modes, error codes, CAS semantics, profile aliases, and the POST /blob sidecar flow. It also tells the agent to call action='describe' for the full per-action reference, covering remaining gaps in an actionable way.

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 meaningful semantics beyond the schema for key parameters: blob_id is the default single-use source for file uploads, content_base64 is a last resort likely to fail above a few MB, content is only for on-the-fly text, filesize must match uploaded bytes to avoid the 10522 trap, and max_size should be overestimated. Not every one of the 40 parameters gets extra treatment, but the critical ambiguous ones are clarified substantially.

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 opens with a specific verb and resource — "File upload" — and immediately enumerates the distinct modes: stream-upload, chunked, web URL import, and batch. This clearly differentiates the tool from siblings like download, storage, and fileshare, and gives an agent a precise mental model of what the tool does.

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?

The description provides an explicit, top-to-bottom UPLOAD STRATEGY with numbered decision rules: use web-import when a URL is available, prefer POST /blob + stream-upload for everything up to 100 MB, switch to chunked only over the cap or when a session id is needed, and use batch for many small files. It also explicitly warns when NOT to use content_base64 and tells the agent to check firewall settings instead, giving clear guidance versus alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool covers a clearly distinct domain (auth, storage, shares, comments, events, AI, etc.), and overlapping concepts like share vs. fileshare are explicitly disambiguated with deprecation notes and cross-references. An agent can reliably select the correct tool for a task without ambiguity.

Naming Consistency3/5

Tool names are all lowercase single words, but they mix nouns (user, org, workspace) with verbs (download, find, upload) and include a hyphenated 'how-to'. There is no consistent verb_noun or noun-only pattern, though the names are still readable and memorable.

Tool Count4/5

19 tools is slightly above the typical 3-15 sweet spot, but the platform's breadth (auth, file management, sharing, collaboration, AI, metadata, and help) justifies this count. Each tool represents a substantial domain area, so none feel redundant.

Completeness5/5

The toolset provides full lifecycle coverage for the platform: authentication, user/org/workspace management, file storage/upload/download/search, sharing (both quickshare and durable file shares), comments, events, metadata pipelines, AI assistance, and product help. No obvious dead ends or missing operations are apparent.

Resources