Skip to main content
Glama
taylorwilsdon

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

by taylorwilsdon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Check Drive File Public Access

check_drive_file_public_access
Read-onlyIdempotent

Search for a file by name to check if public link sharing is enabled, helping you identify and fix exposure risks in Google Drive.

Instructions

Searches for a file by name and checks if it has public link sharing enabled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
drive_idNoID of the shared drive to scope the search to. When set, the underlying files.list call uses corpora='drive' and the given driveId, which is required to reliably find files that live only in that shared drive. When None, behaviour is unchanged (default API corpora applies).
file_nameYesThe name of the file to check.
user_google_emailYesThe user's Google email address. Required.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.28.0
    • removedInput schema / properties / drive_id / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / drive_id / type
      Added value: +"string"
  2. Addedv1.0.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it searches by name and checks public sharing, but does not disclose edge cases like behavior when the file is not found, whether it returns a boolean, or how it handles files in shared drives without drive_id (the schema partially addresses this). This is adequate but not rich.

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, tightly written sentence that states the action and the check. No wasted words, and the purpose is front-loaded. This is exemplary conciseness.

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?

The tool is simple, has a clear description, full schema documentation, and an output schema (not shown but indicated). The description covers the essential purpose, and the schema fills in parameter details. Given the sibling ambiguity, a note about when to choose this over get_drive_file_permissions would improve completeness, but as is it is sufficient for a straightforward check tool.

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 schema already fully documents all three parameters, including the drive_id scoping behavior. The description adds no extra parameter meaning, so the baseline of 3 is appropriate.

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 description states a specific verb+resource: it searches for a file by name and checks if public link sharing is enabled. This clearly distinguishes it from sibling tools like search_drive_files (which just searches) or get_drive_file_permissions (which fetches all permissions). It is unambiguous about the tool's core function.

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 description provides no guidance on when to use this tool versus alternatives such as get_drive_file_permissions or get_drive_shareable_link. It does not mention any conditions or prerequisites, leaving the agent to infer that this is the right tool for a simple public-access check. Given the large sibling list with overlapping permission-related tools, explicit differentiation would help.

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