ZIP uploads

MCP negotiates an upload; a separate HTTPS transfer carries the archive bytes. A local filesystem path on your computer is not a file the remote server can read.

Transfer with an HTTPS-capable uploader

1. Package the source into a ZIP. Calculate its exact byte length and SHA-256 digest.
2. Call prepare_source_upload with project, filename, size and digest.
3. The server returns a short-lived upload_url, upload_ticket and human browser_upload_url.
4. A tool with file access sends the raw ZIP bytes to upload_url using PUT, the ticket in the authorization header, Content-Type: application/zip and matching Content-Length.
5. Call get_source_upload to inspect validation status and obtain the immutable source_upload_id.
6. Use that source ID in a deployment plan with source type zip.

The ticket is a narrow transfer capability. It is not the client’s broad OAuth token. Do not put it in URLs, prompts, command history or logs.

Human upload handoff

If the agent client cannot transfer local files, open the returned browser_upload_url. Sign in to the account that authorized the connection and select the original archive. The browser verifies the expected size and digest before transfer.

The archive must match the intent. You cannot substitute a different ZIP without preparing a new intent. GitHub and Docker remain alternatives when file transfer is unavailable.

Limits and expiry

The default limits are 100 MiB compressed, 1 GiB extracted and 10,000 entries. Upload intents expire after ten minutes. Use the capabilities returned by the server as the source of truth for configured limits.

Archives are validated for size, digest, ZIP integrity and safe paths. Check the status response when validation fails, then prepare a corrected upload if needed.