Skip to main content
Glama
nabheet

google-services-mcp

by nabheet
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Share Drive file

google_drive_share

Share Google Drive files with users, groups, anyone with link, or domains; set access roles and optionally transfer ownership.

Instructions

Share a file with a user/group by email, anyone with the link, or a domain; optionally transfer ownership.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleYesAccess role.
typeNoPermission type (default user).
emailNoRecipient email (required for type user/group).
domainNoDomain for type=domain, e.g. example.com.
fileIdYesDrive file ID.
accountNoAccount nickname to use.
transferOwnershipNoTransfer ownership to the recipient (requires role=owner).
sendNotificationEmailNoEmail the recipient (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.60
    • addedInput schema / properties / domain
      Added value: +{
+  "description": "Domain for type=domain, e.g. example.com.",
+  "type": "string"
+}
    • changedInput schema / properties / email / description
      Previous value: -"Recipient email."New value: +"Recipient email (required for type user/group)."
    • changedInput schema / properties / role / enum
      Previous value: -[
-  "reader",
-  "writer",
-  "commenter"
-]New value: +[
+  "reader",
+  "writer",
+  "commenter",
+  "owner"
+]
    • addedInput schema / properties / transferOwnership
      Added value: +{
+  "description": "Transfer ownership to the recipient (requires role=owner).",
+  "type": "boolean"
+}
    • addedInput schema / properties / type
      Added value: +{
+  "description": "Permission type (default user).",
+  "enum": [
+    "user",
+    "group",
+    "anyone",
+    "domain"
+  ],
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "fileId",
-  "email",
-  "role"
-]New value: +[
+  "fileId",
+  "role"
+]
  2. Changed2 schema fields changedv0.1.30
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / email / pattern
      Added value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  3. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It hints that ownership can be transferred, but does not disclose that transferring ownership typically requires the caller to already be owner, that sharing may be irreversible/security-sensitive, or how notification emails behave - all of which the agent needs for a permission-granting mutation.

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?

A single front-loaded sentence with zero filler; the core action leads and the optional capability trails after a semicolon. Nothing to trim.

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

Completeness3/5

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

The rich schema (8 params, 100% coverage) and absence of an output schema mean the description need not explain parameters or return values. However, with zero annotations, the behavioral/safety context for a permission-granting mutation is left uncovered, which is the one gap the schema cannot fill.

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 enum semantics, email/domain requirements, and the transferOwnership/role=owner dependency is already documented in the schema. The description restates the same concepts (email, link, domain, ownership) without adding format or edge-case detail, so the baseline 3 applies.

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?

States a specific verb (share) and resource (file), and enumerates the three grant modes (user/group by email, anyone with link, domain) that map exactly to the schema's `type` enum. It is distinguishable from siblings like google_drive_list_permissions and google_drive_delete_permission, though it never names them.

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?

The sentence implies the general context (granting access to a file) but gives no when-to-use guidance, no prerequisites, and no routing to alternatives such as list_permissions or update. Nothing tells the agent when this tool is the wrong choice.

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

Deploy Server

Other Tools