Skip to main content
Glama
Sign In
Colab MCP

Colab MCP

by ALiwoto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

upload_file

Destructive

Uploads a local file to a Colab runtime, creating parent directories as needed for any file type. Returns a transfer ID to check progress.

Instructions

Upload a local file to Colab, creating parent directories as needed. Supports arbitrary file types. Requires the Chrome companion and a connected runtime. Returns a transfer_id immediately; use transfer_status to check progress. File bytes do not enter the conversation. Only one transfer runs at a time. Existing files require overwrite=true.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "local_path": "<local_path>",
      "colab_path": "<colab_path>"
    },
    "name": "upload_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
overwriteNo
colab_pathYesAbsolute runtime file path, e.g. /content/data.zip.
local_pathYesAbsolute local file path.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.3/5.0
Behavior3/5

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

With destructiveHint=true in annotations, the description usefully explains what makes it destructive: existing files require overwrite=true, so an agent knows an unflagged call will not clobber data. It also discloses async behavior (immediate transfer_id) and a concurrency limit (one transfer at a time), which annotations cannot convey. The gaps are rate/size limits and failure behavior for partial transfers, so this lands at a solid 3 and does not contradict the annotation.

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?

Six short sentences, each carrying distinct information: purpose, supported types, prerequisites, return value, streaming behavior, concurrency, and overwrite. The main purpose is front-loaded and no sentence is redundant.

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?

There is no output schema, and the description compensates by stating that a transfer_id is returned and that transfer_status is the polling tool. Prerequisites, concurrency constraint, and overwrite semantics cover everything needed to invoke it correctly.

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 67% and colab_path/local_path are already documented, but overwrite has no schema description; the description supplies its meaning (required when the destination file exists), which is genuine added value. It does not explain what overwrite=false does when the file exists, but that is implied.

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?

States a specific verb+resource (upload a local file to Colab) plus a side effect (creating parent directories). It is unmistakably distinct from the sibling download_file and explicitly names transfer_status as the follow-up tool.

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

Usage Guidelines4/5

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

Gives prerequisites (Chrome companion, connected runtime) and the condition that selects overwrite=true for existing files, plus routing to transfer_status for progress. It does not exclude or compare against alternatives such as writing a file via call_notebook_tool, which keeps it short of a 5.

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

Deploy Server

Other Tools