Google Workspace MCP Server

Overview Schema Source Related Servers Discussions Admin

list_drive_items

List files and folders from Google Drive or shared drives, filter by file type, and paginate through results to quickly locate the items you need.

Instructions

Lists files and folders, supporting shared drives. If drive_id is specified, lists items within that shared drive. folder_id is then relative to that drive (or use drive_id as folder_id for root). If drive_id is not specified, lists items from user's "My Drive" and accessible shared drives (if include_items_from_all_drives is True).

Args: user_google_email (str): The user's Google email address. Required. folder_id (str): The ID of the Google Drive folder. Defaults to 'root'. For a shared drive, this can be the shared drive's ID to list its root, or a folder ID within that shared drive. page_size (int): The maximum number of items to return. Defaults to 100. page_token (Optional[str]): Page token from a previous response's nextPageToken to retrieve the next page of results. drive_id (Optional[str]): ID of the shared drive. If provided, the listing is scoped to this drive. include_items_from_all_drives (bool): Whether items from all accessible shared drives should be included if drive_id is not set. Defaults to True. corpora (Optional[str]): Corpus to query ('user', 'drive', 'allDrives'). If drive_id is set and corpora is None, 'drive' is used. If None and no drive_id, API defaults apply. file_type (Optional[str]): Restrict results to a specific file type. Accepts a friendly name ('folder', 'document'/'doc', 'spreadsheet'/'sheet', 'presentation'/'slides', 'form', 'drawing', 'pdf', 'shortcut', 'script', 'site', 'jam'/'jamboard') or any raw MIME type string (e.g. 'application/pdf'). Defaults to None (all types). detailed (bool): Whether to include size, modified time, and link in results. Defaults to True.

Returns: str: A formatted list of files/folders in the specified folder. Includes a nextPageToken line when more results are available.

Input Schema

TableJSON Schema

Name	Required	Default
`corpora`	No
`detailed`	No
`drive_id`	No
`file_type`	No
`folder_id`	No	root
`page_size`	No
`page_token`	No
`user_google_email`	Yes
`include_items_from_all_drives`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.14.3Sep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it delivers: pagination via nextPageToken, default page size, file_type filtering with accepted aliases, and return format. It also explains the nuanced scope behavior for drive_id, folder_id, and include_items_from_all_drives.

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?

The description is longer than average, but the length is justified by 9 parameters and shared-drive complexity. It is front-loaded with purpose and scoping rules before the Args block, and the Returns section is compactly integrated.

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 9-parameter tool with no annotations, the description covers all parameters, the output shape, pagination, and conditional behavior across My Drive and shared drives. Nothing essential for calling the tool correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the Args block is essential. It defines every parameter's purpose, defaults, optionality, and special behavior (e.g., folder_id can be a shared drive's ID for root; file_type accepts friendly names or raw MIME types), far exceeding the schema's bare type information.

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 opens with a specific verb-resource pair: 'Lists files and folders', and immediately distinguishes itself by noting shared-drive support. It is clearly differentiated from siblings like search_drive_files (search) and get_drive_file_content (fetch a single file).

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 explicit conditional usage: if drive_id is specified, the listing is scoped to that drive; otherwise it lists My Drive and accessible shared drives. It does not explicitly name alternatives or say when not to use the tool, but the contextual conditions are clear enough for an agent to choose it appropriately.

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

Deploy Server