Skip to main content
Glama

Fast.io

by io.fast.mcp
OverviewDiscussionsAdmin

Upload Management

upload_manage
Destructive

Fastio uploads (write): stream-upload (one call, auto-finalizes, no filesize), chunked sessions (create-session, chunk, finalize), web URL import, batch (many small files), cancellation. For files and binary the default byte source is the POST /blob sidecar: raw bytes over plain HTTP outside MCP (up to 100 MB, no base64), returning a blob_id for stream-upload/chunk/batch. The chunked path is for files over 100 MB. content is UTF-8 text composed in the call; content_base64 inflates ~33% and fails above a few MB. Uploads create files and consume storage credits; a same-name upload overwrites in place as a new version. Destructive: cancel, cancel-all, chunk-delete, web-cancel. Reads are on upload. action='describe' gives the full action/param reference.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoSource URL to import from.
hashNoHash of the bytes this call sends (a chunk, or the whole stream body). Pair with hash_algo. If both are omitted, the CRC-32C of the bytes is sent.
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.
actionYesOperation. Use 'describe' for full action reference.
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. Base64 goes in content_base64. One of content/content_base64/blob_id.
creatorNoClient identifier echoed back (alphanumeric + hyphens).
blob_refNoAlias for blob_id (deprecated). Accepted on chunk/stream/stream-upload only.
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. An overestimate is safe; omitted, the organization's file-size limit applies. Stream sessions only.
passwordNoFile Share link password (profile_type=fileshare only). Sent only as the x-ve-password header on each call, never in a URL/log; needed 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_algoNomd5, sha1, sha256, sha384 or crc32c (8 lowercase hex). Pair with hash.
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.
file_crc32cNochunk only: CRC-32C of the WHOLE file (8 lowercase hex), checked once all bytes arrive; combine each chunk's returned `crc32c` in order. Send on the first send of the chunk whose CRC completes last (sequential: the last chunk) and its retries; never move it. A different value: 10779; after every byte arrived: 10507.
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 a CRC-32C 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, fileshare.file.id in the File Share's 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.
content_base64NoBase64-encoded **binary**, server-decoded. ⚠️ **LAST RESORT — expect FAILURE above a few MB** (~33% inflation + MCP transport cap). An unreachable POST /blob is almost always a CLIENT-SIDE FIREWALL/PROXY restriction, not a server limit; allowing /blob there lifts it. `blob_id` carries real files.
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 (fileshare.file.id in the File Share's details).
describe_actionNoWith action='describe': return one action's params and notes instead of the action index.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / max_size / description
      Previous value: -"Stream-body byte ceiling — aborts mid-transfer if exceeded. An overestimate is safe; omitted, the plan limit applies. Stream sessions only."New value: +"Stream-body byte ceiling — aborts mid-transfer if exceeded. An overestimate is safe; omitted, the organization's file-size limit applies. Stream sessions only."
  2. Changed5 schema fields changed
    • addedInput schema / properties / file_crc32c
      Added value: +{
+  "description": "chunk only: CRC-32C of the WHOLE file (8 lowercase hex), checked once all bytes arrive; combine each chunk's returned `crc32c` in order. Send on the first send of the chunk whose CRC completes last (sequential: the last chunk) and its retries; never move it. A different value: 10779; after every byte arrived: 10507.",
+  "type": "string"
+}
    • changedInput schema / properties / files / items / properties / hash_algo / enum
      Previous value: -[
-  "md5",
-  "sha1",
-  "sha256",
-  "sha384"
-]New value: +[
+  "md5",
+  "sha1",
+  "sha256",
+  "sha384",
+  "crc32c"
+]
    • changedInput schema / properties / hash / description
      Previous value: -"File hash for verification."New value: +"Hash of the bytes this call sends (a chunk, or the whole stream body). Pair with hash_algo. If both are omitted, the CRC-32C of the bytes is sent."
    • changedInput schema / properties / hash_algo / description
      Previous value: -"Hash algorithm (e.g. 'sha256')."New value: +"md5, sha1, sha256, sha384 or crc32c (8 lowercase hex). Pair with hash."
    • changedInput schema / properties / include_hash / description
      Previous value: -"Compute SHA-256 client-side for entries without a hash (default true when omitted)."New value: +"Compute a CRC-32C client-side for entries without a hash (default true when omitted)."
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare the tool is destructive, and the description goes further by naming exactly which actions are destructive (cancel, cancel-all, chunk-delete, web-cancel), disclosing storage-credit consumption, and explaining that same-name uploads overwrite in place as a new version. These are side-effect details the annotations cannot express.

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?

Front-loaded with the action inventory before byte-source and side-effect details, which is the right ordering for a 12-action tool. It is dense and some clauses (base64 inflation, storage credits) duplicate schema text, but for a 33-parameter mega-tool the length is earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 actions, 33 parameters, and no output schema, the description covers the decision-critical surface: which action, which byte source, size limits, and destructive semantics. It defers the exhaustive action/param matrix to action='describe', which is a reasonable pointer, though per-action return behavior remains unstated.

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 description coverage is 100%, so the baseline is 3. The description still adds cross-parameter routing value beyond the schema by synthesizing which byte source (blob_id vs content vs content_base64) to use and why, rather than restating field definitions individually.

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 specific verb+resource framing ('Fastio uploads (write)') and enumerates the full set of write actions (stream-upload, chunked sessions, web import, batch, cancellation). It explicitly distinguishes itself from the read-side sibling by noting 'Reads are on `upload`', so an agent can route without opening either 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?

The description gives concrete selection rules: the POST /blob sidecar is the default byte source for files and binaries, chunked is for files over 100 MB, `content` is for text composed in-call, and `content_base64` is a rare fallback. It also names the alternative tool for reads and points to action='describe' for the full action/param reference.

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

All Fast.io 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