Skip to main content
Glama

Upload Asset

upload_asset

Upload a binary asset (image, font, audio, …) to the project's hosted storage. This uploads bytes you actually hold — a file you generated, downloaded, or read yourself. Chat attachments don't qualify: the user's attachments never reach MCP servers (you see attached images through vision only; there is no file, id, or URL behind them you can read), so for those use request_user_upload instead and the user re-picks the file in a card that uploads from their browser. Three modes. ChatGPT conversation files — a generated image, a file ChatGPT itself holds: pass the file as the file parameter and the host attaches a download link itself; this server fetches the bytes directly, at full quality (nothing goes through your sandbox or through base64 in arguments; content_type and size_bytes are optional here). Never downscale or re-encode a generated image to fit the inline cap — pass it as file instead. Files up to 3 MB you hold yourself — pass content_base64 plus size_bytes (the decoded byte count) and the upload completes in this call, returning publicUrl. Larger files — pass size_bytes alone to get an uploadUrl; PUT the raw bytes to it with the same content_type and exact byte count (e.g. curl -X PUT -H 'Content-Type: image/png' --data-binary @file.png '<uploadUrl>'), then reference publicUrl. Some sandboxes (claude.ai Cowork, ChatGPT containers) block egress to S3: if the PUT fails in any way — connection failure, proxy error, or a response without an x-amz-request-id header — that block is permanent for the session, so switch paths instead of retrying or re-encoding smaller: the file parameter in ChatGPT for any file that exists in this conversation, content_base64 for files under 3 MB, request_user_upload for user-provided files, or a PUT from inside the project VM via run_code_in_vm (re-mint the URL first; it is short-lived). For AI imagery generated fresh, use generate_image. A single file can be at most 100 MB via the presigned mode (the inline content_base64 mode is capped at 3 MB).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoChatGPT only: a file from this conversation (e.g. a generated image). The ChatGPT host fills download_url/file_id when you reference the file; the values are host-issued and cannot be constructed by hand — on clients without file-parameter support, leave this unset and use the other modes.
file_nameYes
projectIdYes
size_bytesNoRequired unless `file` is set. Exact byte count of the file, as measured from the file itself (e.g. stat/ls -l). With content_base64 it must equal the decoded length; in presigned mode the PUT must send exactly this many bytes.
content_typeNoRequired unless `file` is set (in that mode the type is derived from the downloaded bytes; pass this only as a hint).
content_base64NoThe file's bytes, base64-encoded (≤3 MB decoded). When set, the upload completes in this call.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=false and destructiveHint=false, which are consistent with an upload operation. The description goes far beyond, detailing what happens with each mode, the 3MB/100MB caps, the short-lived presigned URL, the egress block implications, and the exact behavior for the `file` parameter in ChatGPT. It explains the full mechanics without contradicting annotations.

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?

The description is long but well-structured, starting with the core purpose, then branching into modes and edge cases. Every sentence adds necessary information; there is no fluff. It could be slightly more compact, but the complexity of the tool justifies the length. It remains readable and front-loaded.

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?

Given the complexity (6 parameters, nested objects, no output schema), the description covers all essential contexts: mode selection, size limits, egress blocking, alternative tools, and error handling. No critical information is missing, making it fully complete for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While schema coverage is 67%, the tool description adds substantial meaning to every parameter. It explains when `file` is required vs. other modes, how `content_base64` and `size_bytes` must match, the purpose of `content_type`, and the optional status of fields in `file`. It clarifies relationships and provides context the schema lacks, making parameter usage error-proof.

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 states exactly what the tool does: uploads a binary asset to the project's hosted storage. It clearly distinguishes itself from related tools like card_upload_asset, request_user_upload, and generate_image, and explains the three modes. Specific verbs and resources make the purpose unambiguous.

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 explicit guidance on when to use each mode, when to delegate to request_user_upload (for chat attachments), and when to use generate_image for fresh AI imagery. It also discusses sandbox egress blocking and advises path-switching over retrying, effectively preventing misuse. No ambiguity remains.

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

A3.6/5.0
Disambiguation4/5

Tools are mostly distinct, but there is some overlap among file-modifying tools (edit_file, write_file, apply_patch) and between run_code_in_vm and run_code_in_browser. Detailed descriptions and clearly scoped use cases help agents select correctly.

Naming Consistency4/5

Most tools follow a verb_noun snake_case pattern (create_project, list_files, execute_sql), but a few deviate (apply_patch, card_upload_asset, run_code_in_vm). Overall readable and predictable, with only minor inconsistencies.

Tool Count2/5

With 46 tools, the server exceeds the typical well-scoped range and approaches the extreme threshold. While the broad scope of a full development platform justifies many tools, this count may overwhelm agents and increase misselection risk.

Completeness4/5

The tool surface covers the full development lifecycle: project creation, file operations, database management, resource provisioning, deployment, testing, and debugging. Minor gaps exist (e.g., no delete_project or checkpoint management), but core workflows are well-supported.

Resources