Google Workspace MCP Server - Control Gmail, Calendar, Docs, Sheets, Slides, Chat, Forms & Drive

Set Drive File Permissions

set_drive_file_permissions

Destructive

Manage Google Drive file sharing settings: control link access, editor permissions, and download restrictions for any file or folder.

Instructions

Sets file-level sharing settings and controls link sharing for a Google Drive file or folder.

This is a high-level tool for the most common permission changes. Use this to toggle "anyone with the link" access or configure file-level sharing behavior. For managing individual user/group permissions, use share_drive_file or update_drive_permission instead.

Input Schema

TableJSON Schema

Name	Required	Description
`file_id`	Yes	The ID of the file or folder. Required.
`link_sharing`	No	Control "anyone with the link" access for the file. - "off": Disable "anyone with the link" access for this file. - "reader": Anyone with the link can view. - "commenter": Anyone with the link can comment. - "writer": Anyone with the link can edit.
`user_google_email`	Yes	The user's Google email address. Required.
`writers_can_share`	No	Whether editors can change permissions and share. If False, only the owner can share. Defaults to None (no change).
`copy_requires_writer_permission`	No	Whether viewers and commenters are prevented from copying, printing, or downloading. Defaults to None (no change).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.28.0Sep 24, 2026
- removedInput schema / properties / copy_requires_writer_permission / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / copy_requires_writer_permission / type
```
Added value: +"boolean"
```
- removedInput schema / properties / link_sharing / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / link_sharing / type
```
Added value: +"string"
```
- removedInput schema / properties / writers_can_share / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / writers_can_share / type
```
Added value: +"boolean"
```
Addedv1.0.1Jul 31, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to restate that this mutates state. It adds useful scope (file/folder link sharing, not individual grants), but it does not disclose consequences such as making a file public or private, what happens to existing permissions, or whether owner-level privileges are required.

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

Conciseness5/5

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

Three sentences, with the core action front-loaded and every sentence contributing either purpose or usage routing. There is no fluff, repetition of the schema, or unnecessary qualification.

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

Completeness4/5

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

Given the rich schema, output schema, and annotations, the description covers purpose, scope, and routing well. The main remaining gaps are that the required user_google_email is not framed in context and there is no prerequisite note about ownership for destructive sharing changes; overall this is above minimum but not exhaustive.

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 the baseline of 3 applies. The description reinforces the 'link sharing' and 'file-level' context but does not add per-parameter meaning beyond the schema; notably, the role of the required user_google_email is not clarified as acting user versus permission target.

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 lead sentence names a specific action ('Sets...'), a specific resource ('file-level sharing settings and ... link sharing'), and the target ('Google Drive file or folder'). It also explicitly separates this from individual user/group permission management, so an agent can tell it apart from nearby permission tools.

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?

The description explicitly says to use this tool for toggling link sharing and file-level settings, and directs user/group permission changes to share_drive_file or update_drive_permission instead. However, those named alternatives do not appear in the provided sibling-tool list, while the similar-sounding manage_drive_access does, so the routing is somewhat less actionable than it could be.

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

Deploy Server