Skip to main content
Glama

Drive List Files

drive_list_files
Read-onlyIdempotent

Search and list Google Drive files across My Drive, shared files, and shared drives by folder, kind, modification time, full text, or raw query, returning paginated results.

Instructions

Search or list Drive files in My Drive, shared with the user and in shared drives, by folder, kind, modification time, full text or a raw Drive query, all combined with AND. For a quick name lookup across Drive, contacts and Gmail at once use search_workspace, and for one known file use drive_get_file. Returns files (id, name, kind, mime_type, modified_at, parent_ids, owners, web_url, trashed, can_edit), count and next_page_token for the next page; trashed files are included unless the query says trashed = false.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "drive_list_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoOnly files of this kind, the same values as each result's kind: folder, document (Google Doc), spreadsheet (Google Sheet), presentation (Google Slides), form (Google Form), or image, video or audio (any stored file of that media type).
queryNoRaw Drive search query in Drive's q syntax, terms joined with and/or, e.g. "name contains 'budget' and trashed = false" or "starred = true"; combined by AND with folder_id, kind, modified_after and full_text when those are given. Omit it and every filter to list every file the user can access, trashed files included.
drive_idNoShared drive ID from drive_list_drives: search only that shared drive. Omit to search My Drive, files shared with the user and every shared drive they belong to.
order_byNoComma-separated sort keys, each optionally followed by ' desc': createdTime, folder, modifiedByMeTime, modifiedTime, name, name_natural, quotaBytesUsed, recency, sharedWithMeTime, starred, viewedByMeTime; e.g. 'folder,modifiedTime desc'. Omit for Google's default order.
folder_idNoOnly the direct children of this folder (not files in its subfolders); a folder ID from drive_list_files with kind 'folder', or a shared drive ID for its top level.
full_textNoOnly files whose name, description or content contains these words (Drive's fullText search); quotes in the text are escaped for you.
page_sizeNoFiles per page, 1 to 1000.
page_tokenNoThe next_page_token from the previous response of this same call; omit for the first page.
modified_afterNoOnly files last modified after this time: RFC3339 such as '2026-11-01T09:00:00-03:00', or a date such as '2026-11-01' (midnight); a date or a time without an offset is read in the account time zone.

Output Schema

NameRequiredDescriptionDefault
countNoNumber of items in this response.
filesNo
has_moreNoWhether another page is available.
fetched_atNoRFC3339 time when this response was fetched.
next_page_tokenNoOpaque token for the next page, or null.
account_timezoneNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world, so the bar is lower; the description still adds real behavior by disclosing that trashed files are included unless the query says trashed = false, and by enumerating the returned fields. It does not discuss rate limits or result caps, keeping it short of a 5.

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: capability and scope first, then sibling routing, then return shape and the trashed default. Dense with zero filler and front-loaded where it matters most.

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 search tool with an output schema and full annotation coverage, the description supplies everything an agent needs: scope, sibling routing, AND semantics, pagination token, and the non-obvious trashed default. Nothing material is left to inference.

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 is 3. The description does reinforce that all filters combine with AND and that omitting everything lists every accessible file, but that same combination and omission semantics is already stated in the query parameter's schema description, so the added meaning is marginal.

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?

States a specific verb and resource ('Search or list Drive files') plus the exact scope (My Drive, shared with the user, shared drives) and the filter axes. It explicitly names the two siblings it is not, so an agent can pick it without opening a schema.

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

Usage Guidelines5/5

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

Gives concrete routing: use search_workspace for a quick name lookup across Drive, contacts and Gmail, and drive_get_file for one known file. That is an explicit when-to-use-this vs when-to-use-alternative statement, which is rare.

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