Skip to main content
Glama

colab_transfer_upload

Upload files to a Colab runtime with atomic transfer, progress tracking, and automatic resume for failed transfers. Sync mode skips files with identical SHA-256 hashes to avoid redundant uploads.

Instructions

Upload atomically with progress. On failure retain transfer_id/staging_path and resume only on the same fingerprint; otherwise clean staging.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
syncNoTrue skips destinations with the same SHA-256; defaults to true.
sessionNoTracked session name. Null is allowed only when exactly one session exists.
max_filesNoHard file-count limit for a directory transfer.
overwriteNoWhen true, explicitly permit replacement of an existing destination.
chunk_sizeNoTransfer chunk size in bytes; 1-2,000,000. Defaults to 524,288.
local_pathYesPath on the MCP host, resolved under the host user's permissions.
compressionNoWire compression: auto uses gzip only when worthwhile; gzip forces it; none disables it.auto
lease_tokenNoOpaque operation-bound lease from colab_allocation_probe. Null performs a fresh probe.
remote_pathYesRuntime path confined to /content; relative paths resolve under /content.
transfer_idNoOpaque 32-character transfer ID from a failed upload. Reuse it to resume on the same incarnation; null starts a new transfer.
max_total_bytesNoHard total transfer limit in bytes; checked before publication.
compression_min_bytesNoAuto mode only considers files at least this many content bytes; defaults to 1 MiB.
compression_min_savingsNoMinimum fractional wire-byte saving required by auto mode; defaults to 0.10.
Behavior3/5

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

With no annotations provided, the description carries the full burden. It does disclose key behavioral traits: atomicity, progress reporting, and failure handling (retain transfer_id/staging_path, resume on same fingerprint, cleanup otherwise). However, it omits other important behaviors such as return value format, permissions, and whether the operation is synchronous, leaving gaps for an agent.

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

Conciseness5/5

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

The description is two concise sentences that convey atomicity, progress, failure, resume semantics, and cleanup. No filler words; every phrase earns its place.

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

Completeness2/5

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

This is a complex 13-parameter transfer tool with no output schema. The description provides only high-level behavior and does not explain return values, when to use versus alternatives, or how parameters like session, lease_token, or compression interact. It is too sparse to fully inform an agent about correct invocation.

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 all 13 parameters already have detailed descriptions. The tool description adds value by referencing transfer_id and 'staging_path' in context of resume/cleanup, slightly enriching the meaning of these fields, but it does not meaningfully compensate beyond the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Upload atomically with progress'), covering verb and resource. It clearly describes what the tool does, but it does not explicitly differentiate from the sibling tool 'colab_upload', which likely has a similar upload purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like colab_upload. The description lacks any context about prerequisites, recommended scenarios, or exclusions, leaving the agent to guess when this tool is the right choice.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/anluin/colab-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server