Skip to main content
Glama
iTvX

Google Workspace MCP — Gmail edition

by iTvX

manage_drive

Search, upload, download, share, comment on, or manage Google Drive files. Use it to handle permissions, folders, file transfers, and comments.

Instructions

Search, upload, download, share, comment on, or manage files in Google Drive.

Input Schema

NameRequiredDescriptionDefault
nameNoFile name in Drive. On `upload`, defaults to the local file's name. On `copy`, the name for the copy — without it Drive names it 'Copy of <original>'. On `update`, the new name (a rename). On `createFolder`, the folder name.
roleNoPermission level. On `share`, the level to grant — defaults to `reader`. On `setRole`, the new level, and it is REQUIRED there: with no default to fall back on, an omitted role would silently demote the collaborator, and setRole sends no notification.
typeNoPermission type (default: 'user'). Use 'group' for Google Groups, 'domain' to share with an entire G Suite domain, 'anyone' for public links.
emailYesAccount email address. On list operations, "all" runs it once for every configured account.
queryNoDrive search query (e.g. "name contains 'budget'" or "mimeType='application/pdf'")
domainNoDomain name (required when type is 'domain').
fileIdNoFile ID
contentNoComment text. On `replyToComment`, the reply text.
filePathNoLocal file path to upload
folderIdNoFolder ID (pass the id returned by createFolder or search)
maxDepthNoHow many folder levels to descend (default 10). The tree is labelled partial when this limit stops the walk.
mimeTypeNoTarget format (e.g. application/pdf, text/csv, text/plain, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
resolvedNotrue to resolve, false to reopen
commentIdNoComment ID
operationYessearch: find files by query | get: get file metadata | upload: upload a local file to Drive | viewImage: view an image file inline without saving to workspace (png, jpg, gif, webp). Use for quick preview — use download to save. | download: download file content to local path | copy: create a copy of a file (set name to rename the copy; parentFolderId to place it in a folder) | update: rename a file (set name) and/or move it between folders (addParents / removeParents — to move, set both) | delete: permanently delete a file (cannot be undone) | trash: move a file or folder to trash (recoverable for 30 days — use instead of delete when you only need to remove it) | export: export a Google Workspace document (Docs, Sheets, Slides) to a file format | createFolder: create a new folder (optionally nested under a parent folder) | listFolder: list the files and subfolders directly inside a folder | tree: print a recursive folder tree and count the files (subfolders excluded from the count) | listPermissions: list sharing permissions on a file | share: share a file with a user, group, domain, or anyone | unshare: remove sharing permission from a file | setRole: change an existing collaborator's role (no notification email is sent) | listComments: list comments on a file | getComment: get a specific comment by ID | addComment: add a comment to a file (optionally anchored to quoted text) | resolveComment: resolve or reopen a comment | replyToComment: reply to an existing comment
addParentsNoComma-separated folder ID(s) to add as parents (move into a folder)
maxResultsNoMax results (default: 10, max: 50)
outputPathNoLocal path to save the file
quotedTextNoText to anchor the comment to (optional — if provided, comment is anchored to first occurrence)
shareEmailNoEmail address of the collaborator. On `share`, required when type is 'user' or 'group'; omit for 'domain' (use the `domain` param) or 'anyone'. On `setRole`, the existing collaborator whose role to change.
permissionIdNoPermission ID to remove (from listPermissions)
removeParentsNoComma-separated folder ID(s) to remove as parents (move out of a folder)
includeDeletedNoInclude deleted comments (default: false)
parentFolderIdNoDestination folder ID. On `upload`, places the file in this folder. On `copy`, defaults to the source file's folder. On `createFolder`, nests the new folder under this parent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.8.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, so the description carries the full behavioral burden and delivers essentially none — no mention of auth requirements, quota limits, notification behavior, or which operations are destructive/irreversible. Only an implicit hint that write actions (upload, share) exist.

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?

A single front-loaded sentence with no redundancy or wasted clauses. It is efficient, though its brevity for a 22-operation tool borders on under-specification rather than pure conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 24-parameter mega-tool dispatching 22 operations with no annotations and no output schema, one generic sentence is far too thin. It never tells the agent that this is an operation-dispatch tool or that the operation enum is where the real contract lies.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (including the richly documented operation enum) is already explained in the schema. The description adds no parameter meaning beyond that, making baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (Google Drive files) and lists concrete verbs (search, upload, download, share, comment), so the domain is clear. It fails to distinguish this dispatcher from adjacent siblings like manage_docs, manage_sheets, or manage_workspace, and the trailing 'or manage files' is filler.

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

Usage Guidelines2/5

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

There is no when-to-use, when-not-to-use, or alternative-selection guidance at the description level. The operation-level routing lives entirely in the schema enum, so the description itself provides no decision support.

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