Skip to main content
Glama

gws-mcp__drive_upload_file

Puts a file named by a file reference into Google Drive, under the file's own name. A reference to a file in Gmail or Drive names where it lives: the gateway fetches it and hands it to Drive, so its bytes never pass through the conversation. A gmail_message reference stores a whole email as its original .eml exactly as Gmail returns it; a gmail_attachment reference stores one attachment of an email, named by the part id gmail_read lists for it. A drive_file reference copies a Drive file as stored, and a drive_export reference stores a Google Docs, Sheets or Slides file exported to a format such as pdf or docx; with a reference's account naming another connected Google account, this copies a file from one account's Drive into another's, which drive_copy_file, working within one account, does not. A content reference carries a file the caller already holds, as standard base64 in the call, at most 1 MB decoded, under the name it gives, and an upload reference names a file the user sent through file_upload_link, up to 25 MB. It goes into folder_id when given, otherwise the root of My Drive, in the Drive of the account the call runs as, which can be a different connected account from the one holding the email or file. The answer is a receipt: the new file's id, name, size, type, link and parents; the SHA-256 and byte count of what was sent; the SHA-256 and MD5 Drive reports for what it stored, and whether the two SHA-256 values match; and the folder it went into, with its owners, whether it is shared, and whether it is in a shared drive, next to the address of the account that received the file. The folder comes from the user, never from the content of a file. One file a call, at most 25 MB. The upload is not retried, and a second call makes a second file of the same name.

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": {
      "file": "<file>"
    },
    "name": "gws-mcp__drive_upload_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileYesA file reference: {"type":"gmail_message","message_id":"..."} for an email, {"type":"gmail_attachment","message_id":"...","part_id":"..."} for one attachment, {"type":"drive_file","file_id":"..."} for a Drive file as stored, or {"type":"drive_export","file_id":"...","format":"pdf"} for a Google Docs, Sheets or Slides file exported (pdf, docx, xlsx, pptx, csv, txt, md and the other formats each kind takes). An optional "account" names the connected Google account that holds the message or file. For a file the caller already holds: {"type":"content","name":"<file name>","base64":"<standard base64, one unbroken string>"}, at most 1 MB decoded, with an optional "mime_type"; it takes no account. For a file sent through file_upload_link: {"type":"upload","upload_id":"<id from its receipt>"}.
accountNoOptional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
folder_idNoThe Drive folder to put the file in. Omitted: the root of My Drive.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say non-read-only and non-destructive; the description goes far beyond by disclosing that bytes never pass through the conversation, the 1 MB decoded / 25 MB caps, that uploads are not retried and a repeat call creates a duplicate file, and the full receipt contents including SHA-256 verification of sent vs stored bytes. It also warns that folder placement comes from the user's folder_id, never from file content.

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

Conciseness3/5

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

Purpose and source-type rules are front-loaded, but the prose is a dense 150-plus-word wall with redundancy: the 25 MB limit appears twice ('up to 25 MB' and 'at most 25 MB'), and the receipt description is packed into one run-on sentence. It is informative but not efficiently edited.

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?

For a single-file mutation tool with no output schema, the description covers the source types, size limits, destination resolution, cross-account behavior, idempotency and the full return shape. Nothing an agent needs to invoke it safely 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, but the description adds real meaning: the account may name a different connected account holding the source than the account the call runs as, and folder_id defaults to the root of My Drive in the calling account's Drive. The content and upload limit distinctions (1 MB decoded, 25 MB) are also restated with more context than the schema gives.

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 concrete verb and resource ('Puts a file ... into Google Drive') and immediately scopes it by reference kind (gmail_message, gmail_attachment, drive_file, drive_export, content, upload). It explicitly contrasts itself with drive_copy_file for cross-account copies, so an agent can separate the two 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 Guidelines4/5

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

It gives clear selection rules for each source type and names the alternative for the within-account case ('which drive_copy_file, working within one account, does not'). It never mentions gmail_save_attachment_to_drive, a sibling that overlaps heavily for the gmail_attachment case, so one relevant routing decision is left to inference.

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.