Skip to main content
Glama

Upload to storage

upload_to_storage
Idempotent

Put files from disk into a project's bucket (add_storage), with no server involved. Use it for a static site's images, videos, and downloads such as installers, which keep the deploy bundle under its 50 MiB cap, and to seed any app's bucket with files. First deploy_project, then add_storage (public: true for files the site links to), then this: pass project_id and the files' paths relative to the folder the command will run from, and run the returned command with bash from that folder. It PUTs each file straight to the bucket over a signed URL that works for 30 minutes; the key never leaves spawnpoint. Each path is the file's key in the bucket: on a public bucket the file is then readable by anyone at the url the answer gives for it, which is what the site's HTML links to; on a private bucket only the app's own key reads it. At most 50 files per call (call again for more), each of any size the plan's bucket limit allows. Refused while the bucket is over that limit. Uploading to a key that exists replaces the file.

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": {
      "project_id": "<project_id>",
      "files": "<files>"
    },
    "name": "upload_to_storage"
  }
}

Input Schema

NameRequiredDescriptionDefault
filesYespaths of the files to upload, relative to the folder the returned command runs from, such as img/logo.png or downloads/app.zip; each path becomes the object's key in the bucket, so it is read at <public_url>/<path> on a public bucket. Letters, digits, dots, dashes, underscores, and slashes; no spaces. At most 50 per call
project_idYesthe id of the project that has the bucket

Output Schema

NameRequiredDescriptionDefault
noteYes
filesYes
bucketYes
publicYes
commandYes
warningNo
expires_atYes
project_idYes
public_urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: discloses that the upload is a direct PUT over a signed URL valid for 30 minutes, that the key is never exposed, the 50-file per-call cap, refusal when the bucket exceeds the plan limit, and that an existing key is replaced. The one rough edge is overwrite-on-existing-key sitting alongside destructiveHint=false, which an agent might read as non-destructive despite replacement; the idempotentHint=true is consistent with the replace semantics.

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?

Purpose and prerequisites are front-loaded and almost every sentence carries real information (auth model, size caps, overwrite behavior). It is a dense single block, though, and the path-equals-key point is repeated in both the description and the schema, adding length without new meaning.

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?

Even though an output schema exists and return values need not be explained, the description covers the returned command, how to execute it, per-file URL readability on public vs private buckets, and the size/count limits. Nothing an agent needs to call this correctly is missing.

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; the description still adds operational meaning by framing files as paths relative to the run folder, tying each path to its bucket key and public URL, and clarifying that project_id identifies the bucket owner. Some of this restates the schema's own wording rather than extending it.

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 and resource ("Put files from disk into a project's bucket"), scopes it against add_storage, and adds a distinguishing trait ("with no server involved"). An agent can tell this apart from bucket-creation tools 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?

Gives an explicit ordered workflow (deploy_project, then add_storage with public: true, then this) and names the concrete use cases it serves: static-site assets and seeding an app's bucket. The precondition that paths are relative to the folder where the returned command runs is stated up front, so invocation conditions are unambiguous.

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.