Google Drive

Use this as the top-level router for Google file work inside the unified Google Drive plugin. Do not route the user toward separate Google Docs, Google Sheets, or Google Slides plugins.

Start with Google Drive for file discovery and file lifecycle tasks, then route to narrower sibling skills only when the task becomes specific to Docs, Sheets, or Slides.

Workflow

1. Ground the target file first.

• If the user did not provide an exact file URL or ID, use Google Drive search, recent files, folder listing, or metadata reads to identify the right file.
• If the request starts as "find X and then update it," do the Drive discovery step first instead of guessing the target.

2. Stay in the base Google Drive workflow for Drive-native tasks.

• Use the base workflow for search, fetch, recent files, folders, sharing, copying, deleting, exporting, revision history, file moves, and other file-lifecycle work that is not primarily about editing Docs, Sheets, or Slides content.
• For version-history requests, including "previous version," "revision history," "what changed since the last version," or "compare to the prior revision," ground the file, fetch the current content, use list_file_revisions, fetch the immediately previous revision or the user-named revision with fetch_file_revision, then compare the fetched revision against the current content. Do not say previous versions are unsupported until you have checked whether revision tools are available for the target file.
• For file move requests, ground the source file and target folder, read the file metadata including its current parents, then use update_file with addParents for the target folder and removeParents for only the verified source parent or parents that should no longer contain it. Preserve unrelated parents, and verify the move by reading metadata or listing the target folder before the final response.
• Before any export or raw-file fetch, read or reuse Drive metadata so the MIME type and Google Drive URL are known. Use export_file only to convert a native Google Doc, Sheet, or Slide into an explicitly requested format; it returns an authenticated file reference, not inline bytes or base64. Google limits files.export responses to 10 MB; oversized exports fail rather than returning truncated content. For a larger native PDF, use download_file(id=file_id, mime_type="application/pdf") when the streaming action is available. It calls Google's files.download API and returns a top-level materializable file_uri. Once download_file is unavailable and canonical fetch uses that streamed download path, use fetch(url=google_drive_url, download_raw_file=True, raw_export_mime_type="application/pdf") instead. A native-file fetch that still uses files.export cannot bypass the 10 MB limit. For PDFs, images, ZIPs, Office files, recordings, and other stored, non-native files, use fetch(url=google_drive_url, download_raw_file=True). Use only the authenticated top-level file_uri or materialized workspace_path; never request inline base64 unless an existing caller explicitly opts into bounded legacy compatibility. Use fetch without download_raw_file for bounded, best-effort readable text. Do not retry export_file after metadata shows a non-native MIME type.