Skip to main content
Glama

Drive as a filesystem

drive

Manage Google Drive files and folders with shell-style commands like ls, find, mkdir, cp, mv—search all content, copy formatting, and move items across accounts and shared drives.

Instructions

Navigate and reorganise Google Drive with shell commands: ls, find, mkdir, cp, mv. Arguments are positional and follow the usual shell forms. ls [path] — list a folder (default My Drive root). find [-type d|f] — search everything by name, including files no path can reach. mkdir [-p] — create a folder. cp — duplicate a file (preserves headers/footers, image sizing and exact formatting, which a markdown round-trip cannot rebuild). mv — move and/or rename, as on a filesystem: an existing folder as means "into it", anything else means "to that name". Paths start with / or ~ (My Drive); /shared/ is a shared drive, /shared-with-me the files others shared with you, and /lost+found the files you own that are in no folder at all. Anything not starting with / or ~ is read as a Drive id or URL, so ids from any other tool can be pasted straight in. Drive permits two files with the same name in one folder and folds case when matching, unlike any real filesystem — a path that matches more than one thing is refused with the candidates listed, never guessed. Content is edited with edit_doc/overwrite_doc, not here; there is no rm.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cmdYes
argsNopositional arguments for cmd, e.g. ["/Work/Roof", "/Archive"] for mv
accountNoGoogle account email to use. Defaults to GDOCS_DEFAULT_ACCOUNT, or the sole account.
expectNameNomv only: the name the source is expected to have; the move is refused if it resolved to something else
acceptOwnershipTransferNomv only: required to move into /shared/… , which hands ownership to that drive's organisation and cannot be undone
Behavior5/5

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

With no annotations, the description carries the full burden. It discloses key behaviors: cp preserves formatting that markdown cannot rebuild, ambiguous paths are refused with candidates listed rather than guessed, duplicate names are allowed, and case folding occurs. These are non-obvious and critical traits beyond what the schema or annotations could convey.

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?

The description is long but every sentence contributes unique value. It is well-structured: overview, then per-command details, path conventions, edge cases, and exclusions. No filler or redundancy; it front-loads the core purpose and flows logically. The density is appropriate for a tool with multiple subcommands.

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 multi-command filesystem interface with no output schema, the description covers all essential aspects: each command's behavior, path resolution rules, special directories, handling of duplicate names and case folding, disambiguation on ambiguity, and explicit exclusions. It also notes ownership transfer implications indirectly through schema, but the description itself is self-sufficient for a complex tool.

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?

The description adds substantial meaning beyond the schema for the primary cmd parameter, detailing each subcommand's syntax, defaults, and special flags (e.g., '-p' for mkdir, '-type' for find). It also clarifies the 'args' parameter as positional and provides concrete examples. Even though schema coverage is 80%, the description enriches the semantics of the two most complex parameters (cmd and args) significantly.

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 clear verb+resource: 'Navigate and reorganise Google Drive with shell commands: ls, find, mkdir, cp, mv.' It immediately distinguishes from sibling tools by stating content editing is done elsewhere ('edit_doc/overwrite_doc, not here') and explicitly notes 'there is no rm.' This precisely defines the tool's scope and differentiates it from sibling content manipulation tools.

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?

The description provides extensive usage context: path syntax ('/shared/<drive name>', '/shared-with-me', '/lost+found'), handling of IDs/URLs ('ids from any other tool can be pasted straight in'), and the nuance of mv with an existing folder. It also explicitly excludes content editing (via edit_doc/overwrite_doc) and warns against expecting rm, making the tool's place among siblings clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dasasian/gdocs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server