Google Drive MCP
Three different things get called Google Drive MCP. What each can actually do, where it breaks for agent work, and when to use something else.
Last updated 5 August 2026
Three different things get called "Google Drive MCP" and they behave differently. This page covers what each one is, what it can actually do to a file, and the point where using Drive as your agents' working directory stops working. Every limit below is linked to Google's own documentation, because most of them are not obvious until an agent has already made a mess.
The three things people mean
1. Google's official Drive MCP server
Google ships its own remote MCP server for Drive. It went into public developer preview in May 2026, alongside servers for Gmail, Calendar and Chat. It speaks Streamable HTTP and authenticates with OAuth.
https://drivemcp.googleapis.com/mcp/v1
This is the one to use if you want Drive in an agent today. Per Google's setup guide, adding it to Claude as a custom connector needs a Claude Pro, Max, Team or Enterprise plan.
2. Claude's built-in Google Drive connector
Anthropic ships a Google Drive connector directly in Claude, which is not MCP and needs no endpoint or config block. You turn it on in Settings and approve Google's OAuth screen. On Team and Enterprise plans an owner has to enable it for the organisation first. It reads Docs directly, pulls Sheets as CSV and extracts Slides as text.
3. The archived community server
Beyond those three, hosted gateways such as Composio, Zapier MCP and Pipedream expose Drive through their own MCP endpoints. They add write actions the official server lacks, and they add a third party sitting between your agent and your documents.
What the official server can actually do
Eight tools, per Google's MCP reference: search_files, read_file_content, create_file, copy_file, download_file_content, get_file_metadata, get_file_permissions and list_recent_files.
Read that list again for what is missing. There is no update_file, no delete_file and no move_file. The server can search, read and create. It cannot change a file that already exists.
That single gap sets the shape of everything downstream. An agent asked to revise a document has to read it, rebuild the whole thing, and create a new file with a new ID. The original stays where it was. Someone filed exactly this against Anthropic's connector: every edit "leaves the original file orphaned in Drive" and the user has to trash it by hand, "every single time, for every iterative edit". That request is also closed as not planned. Ten passes over a document leave you ten files and no way to tell which one is current.
Where Drive breaks as agent working storage
None of the following is a bug. Drive was built for people who edit documents, and it is good at that. These are the places where that design and an agent fleet pull in opposite directions.
Revisions are purged on a rule most people never read
For uploaded files, Google's revision documentationstates that revisions are "typically preserved for 30 days, but can be purged earlier if a file has 100 revisions that aren't designated as Keep Forever and a new revision is uploaded". Keep Forever is a flag you set per revision, and no more than 200 revisions per file can carry it. The current version is never purged, so nothing looks broken. The history behind it thins out quietly.
An agent writing every few minutes hits 100 revisions in an afternoon. Google describes a different mechanism for native Docs, Sheets and Slides, where revisions may be merged rather than purged, and does not publish the same explicit window for them.
The record names the account, not the agent
This is the one that matters most and is the hardest to see coming. Drive's Activity API describes an actor as one of five things: a user, anonymous, an impersonation, the system, or an administrator. There is no application actor. A write made by an agent through OAuth is recorded against the human whose token it used.
Run three agents on one connection and the history shows one name three times. "Which agent rewrote this?" has no answer in the record, and neither does "which agent should never have been able to reach this folder".
Restore is per file, and there is no point in time
Version history restores one file to one earlier revision. Drive has added a bulk restore, but it works file by file: you still pick each file's target version from its own history, and Google's page notes you cannot select individual files within a batch. There is no way to say "put this whole folder back to how it looked at 15:00 yesterday".
A bad agent run does not touch one file. It touches the eleven it decided were related. Recovering that means opening eleven version histories and knowing, for each, which revision predates the run.
Quota is priced per operation
Drive's API quotas are measured in units, not calls, and the cost varies by method: a metadata read is 5 units, a write is 50, a listing is 100 and a download is 200. The per-user ceiling is 325,000 units per minute. Search-heavy agents burn it fastest. Over the line you get a 403 or 429 and are expected to back off and retry.
When Google Drive MCP is the right answer
Often. It is free, it is already in the building, and for a large class of work it is the correct tool:
- The documents already live in Drive and people edit them there. Do not copy those somewhere else.
- The agent reads more than it writes. Research, summarising, answering questions over existing files.
- Output is a new artefact each time. A report, a draft, an export. Create-only is a fine fit for create-only work.
- A human reviews everything before it matters. Attribution gaps hurt less when a person is the last step.
If that is your situation, connect Google's server and stop reading. You do not have a problem to solve.
When you need a drive built for agents
The other shape of work is agents writing to the same tree, repeatedly, without a human between each pass. Shared notes, plans, datasets that get transformed, scratch files that outlive one session, state passed from one agent to the next. There the four limits above compound: edits become duplicates, history thins, the record cannot name the writer, and recovery is manual.
Layven is a drive for that case. Same connection method, one config block, different guarantees.
| Google Drive over MCP | Layven | |
|---|---|---|
| Edit an existing file | Not in the official server. Create a new file | Yes, as a new version of the same file |
| Version history | 30 days or 100 revisions for uploads, whichever comes first | Every write, kept for your plan's window |
| Keep a version | Manual flag, 200 per file | Automatic, nothing to remember |
| Who made the change | The account whose OAuth token was used | The named agent token, to the second |
| Restore a folder to a moment | No, per file only | Yes, one call for the whole prefix |
| Scope an agent to a path | No, OAuth scopes cover the whole Drive | Per token, allow and deny prefixes |
| Undo the undo | No | Yes, a restore is itself a version |
| Cost model | Free, quota measured per operation | Flat monthly, operations not metered |
The honest trade: Drive holds the documents your colleagues open, and Layven does not replace that. Layven holds what your agents are working on. Most fleets end up with both connected, which is fine, because an agent can hold two drives at once and the config for each is a URL and a token.
Next
Connecting Layven takes about two minutes in any client: Claude, Claude Code, Cursor, ChatGPT, or any other MCP client.