Google Drive MCP Server: Which One Should You Use?

By Buzz • Invalid Date

#google drive#mcp server#oauth#google workspace#claude desktop

Bottom line up front: Searching for a Google Drive MCP server turns up four meaningfully different implementations — the official Anthropic reference server, Google’s own managed cloud endpoint, and at least two community builds. Most guides only document one of them. This post compares all four across capabilities, OAuth security model, transport type, and deployment fit, so you can pick the right one for your setup.

Why this comparison matters

The SERP for “google drive mcp server” is dominated by GitHub READMEs, directory listings, and Google’s own cloud docs. None of them explain what is actually available or how the options differ. If you have tried to connect Claude or another MCP client to Google Drive and found setup instructions that contradict each other, that is because you were looking at different servers.

The four implementations covered here:

  1. @modelcontextprotocol/server-gdrive — the official Anthropic reference server
  2. felores/gdrive-mcp-server — a popular community TypeScript implementation
  3. michaelpine25/googleDriveMCP — a community build targeting Claude Desktop specifically
  4. Google Cloud managed MCP — Google’s own fully-hosted remote endpoint

They are not interchangeable. The right choice depends on whether you need read-only or read-write access, whether you are running Claude Desktop locally or using Claude.ai on the web, and how seriously you need to think about OAuth scope hygiene.

The four Google Drive MCP servers compared

1. The official Anthropic reference server (server-gdrive)

This is the canonical implementation maintained in the modelcontextprotocol/servers monorepo under src/gdrive. It is the server most often referenced in documentation but least often explained in detail.

What it exposes:

  • search — full-text search across your Drive
  • read_file — retrieves file contents by ID
  • Automatic conversion: Google Docs export to Markdown, Google Sheets export to CSV, Google Slides export to plain text

What it does not expose:

No write, create, delete, move, rename, or permissions management. This is a read-only server. If you ask it to create a file or modify a document, it cannot do it.

Authentication:

OAuth 2.0 with a locally stored token.json. You create OAuth credentials in Google Cloud Console (Desktop App type), run the auth flow once to generate the token file, and point the server at it via environment variables. The scope requested is https://www.googleapis.com/auth/drive.readonly — read-only access to the entire Drive.

Transport: stdio (local subprocess). Works with Claude Desktop. Does not work directly with Claude.ai web without a remote wrapper.

Best for: Read-and-analyze workflows in Claude Desktop. Summarize documents, search across files, pull data from Sheets for analysis. Zero write risk.

2. felores/gdrive-mcp-server

A community TypeScript implementation with a tighter, more deliberate interface than the reference server. Maintains ~65 stars on GitHub at time of writing.

What it exposes:

  • gdrive_search — accepts a query string, returns file metadata
  • gdrive_read_file — accepts a file_id, returns file contents
  • Some forks and integrations add gsheets_read and gsheets_update_cell for Sheets-specific read/write operations

Authentication:

OAuth 2.0 via a browser flow. You place your gcp-oauth.keys.json in a credentials directory and run node dist/index.js auth to open a browser window and complete the flow. Credentials are saved to credentials/.gdrive-server-credentials.json as a refresh token. Environment variables GOOGLE_APPLICATION_CREDENTIALS and MCP_GDRIVE_CREDENTIALS are used to configure the Desktop client integration.

Transport: stdio (local subprocess). Claude Desktop compatible via standard MCP JSON config.

Best for: Developers who want a leaner, more maintainable codebase than the monorepo reference server, or who need a starting point for extension. The credential management is well-structured for local development.

3. michaelpine25/googleDriveMCP

Built specifically to connect Claude Desktop to Google Drive. The setup documentation is one of the more thorough among community implementations.

What it exposes:

  • File listing and folder navigation
  • File content reading
  • OAuth credential management integrated into the setup flow

Authentication:

OAuth 2.0 Desktop App flow. The setup walks through Google Cloud Console credential creation (explicitly requiring Desktop app as the application type, not Web Application), .env file configuration with CLIENT_ID, CLIENT_SECRET, and REDIRECT_URI, and a npm run tokenGenerator step that opens a browser to authenticate and saves token.json to the project root.

Transport: stdio via node command in the Claude Desktop claude_desktop_config.json.

Best for: Developers specifically targeting Claude Desktop who want explicit, well-documented setup steps. Good starting point for non-experts setting up their first Google Drive MCP integration.

4. Google Cloud managed MCP (docs.cloud.google.com/mcp)

This is a fundamentally different category. Google’s managed MCP endpoints are remote, fully-hosted HTTP services running on Google’s infrastructure. They are not a GitHub repo you clone and run locally.

What it exposes:

A significantly broader tool surface than any community implementation:

  • List Folder Items, List Files, Search Files
  • Get File Content, Get File Permissions
  • Create File, Create Folder, Upload File
  • Update File, Copy File, Move Item, Rename Item
  • Trash Item, Restore Item
  • Share Item, Update Permission, Remove Permission

This is effectively full Drive API coverage wrapped in MCP tooling.

Authentication:

Google Cloud IAM. You need a GCP project with the MCP API enabled. Tool callers require the roles/mcp.toolUser IAM role. The client configuration uses an httpUrl pointing to the Google-hosted endpoint plus an oauth block with a scopes array. Admins can enable or disable specific MCP servers at the organization level via IAM and organization policies.

Transport: Remote HTTP(S). Compatible with Claude.ai web (which requires remote MCP endpoints) and any MCP client that supports the HTTP transport. Does not use stdio.

Best for: Enterprise teams who need full read-write Drive access, shared drive support, and do not want to manage locally-running servers. Also the only option if you are using Claude.ai on the web rather than Claude Desktop, since the web interface requires remote MCP endpoints.

Capability matrix

Official server-gdrivefelores/gdrive-mcp-servermichaelpine25Google Cloud managed
Read filesYesYesYesYes
SearchYesYesYesYes
Write / createNoNo (some forks)NoYes
Delete / trashNoNoNoYes
Permissions managementNoNoNoYes
Shared drive supportUnconfirmedUnconfirmedUnconfirmedYes
Docs → MarkdownYesYesYesExport-based
Sheets → CSVYesYesUnconfirmedExport-based
TransportstdiostdiostdioRemote HTTP
Claude DesktopYesYesYesYes (via HTTP config)
Claude.ai webNoNoNoYes
GCP project requiredNoNoNoYes
ComplexityLowLowLowMedium-High

The OAuth security angle most guides skip

Every setup guide tells you to create OAuth credentials. Almost none of them explain what those credentials actually permit or why it matters.

OAuth scope selection is a security decision, not a box-checking step.

The community implementations and reference server typically request drive.readonly — which grants read access to your entire Drive. That sounds safe, and for a read-only server it is appropriate. But there are three things worth understanding:

1. The scope you grant persists in the token.

When you run the OAuth flow and save token.json, that file contains a refresh token that will silently reauthorize the server on every future request. If your token.json is stored in a project directory and that project is pushed to a public repository, you have just published live credentials with full read access to your Drive. This is not theoretical — it happens regularly.

Mitigation: add token.json, credentials/.gdrive-server-credentials.json, and any .env files to .gitignore before your first commit.

2. Desktop App OAuth type has different security properties than Web Application.

The setup guides that specify “Desktop app” as the OAuth credential type are correct, but they do not explain why. Desktop App credentials do not have a client secret that is actually secret — anyone with the credential JSON can initiate an OAuth flow as your application. This is acceptable for local development but means you should not share your gcp-oauth.keys.json file.

3. Full drive scope versus drive.readonly.

If you extend a community server to support write operations, you will need to upgrade from drive.readonly to drive.file (access only to files the app creates or opens) or drive (full access to everything). The difference between drive.file and drive is significant for multi-tool agent deployments — an agent with drive scope and a write-capable MCP server can modify, overwrite, or delete any file in your Drive based on a prompt instruction. Scope to the minimum required.

For enterprise deployments using Google Cloud managed MCP, the IAM model gives admins control that OAuth-file-based setups do not — you can restrict which users can invoke MCP tools, audit tool calls through Google Cloud Logging, and revoke access without touching credential files.

Remote vs local transport: why this determines your deployment path

This is the architectural distinction that most guides completely ignore.

Local stdio servers (all three community implementations) run as a subprocess on the same machine as your MCP client. Claude Desktop spawns the server process, communicates with it over stdin/stdout, and kills it when the session ends. The OAuth credentials live on your local machine.

Implications:

  • Only Claude Desktop (or similar local MCP hosts) can use these servers
  • You cannot share a local stdio server with teammates
  • Each developer needs to run their own instance with their own OAuth credentials
  • No way to access these from Claude.ai on the web

Remote HTTP servers (Google Cloud managed MCP) run on external infrastructure and expose an HTTPS endpoint. MCP clients connect to this URL and authenticate via OAuth or IAM rather than reading a local credential file.

Implications:

  • Works with Claude.ai web, which requires remote endpoints
  • A single deployed instance can serve multiple users with IAM-controlled access
  • Centralized audit logging
  • Requires GCP project setup and IAM configuration — more complexity upfront, but significantly better for teams

If your use case is personal productivity with Claude Desktop, a local stdio server is the right choice and is much faster to get running. If you are deploying MCP for a team or using Claude.ai on the web, the Google Cloud managed endpoint is the only option that fits the architecture.

Google Workspace MCP vs Google Drive MCP

One distinction searchers often conflate: “Google Drive MCP server” and “Google Workspace MCP server” are not the same thing.

The community implementations are Google Drive-specific — they interact with the Drive API and focus on file storage and retrieval.

Google’s managed MCP offering covers the broader Workspace suite. Beyond Drive, Google has published managed MCP endpoints for Google Calendar, Gmail, Google Sheets, Google Docs, Google Slides, and other Cloud services. Each is a separate endpoint with its own tool surface and IAM configuration.

If your workflow touches multiple Google services — for example, you want Claude to read a Drive document, reference a Calendar event, and summarize emails — the Google Cloud managed MCP architecture handles this more cleanly than trying to chain multiple community servers. The tradeoff is the GCP setup overhead.

The keyword google workspace mcp server is growing faster (136% QoQ) than google drive mcp server (85% QoQ), which suggests teams are increasingly thinking about Google integration at the Workspace level rather than service-by-service.

Real-world use cases by server type

With the official reference server or felores (read-only, Claude Desktop):

  • “Find all documents in my Drive from Q4 2025 that contain the phrase ‘budget revision’ and summarize the key figures”
  • “Read the Sheets file with ID [file_id] and tell me which rows have a value greater than 10,000 in column C”
  • “Search my Drive for any documents related to vendor contracts and list them with their last modified date”

With Google Cloud managed MCP (read-write, Claude.ai or Claude Desktop):

  • “Create a new folder called ‘Project Alpha’ in my Drive and move all files containing ‘alpha’ in the title into it”
  • “Read the project brief document and create a summary doc in the same folder”
  • “Find the Q3 report, copy it as a template, rename the copy to Q4 report, and share it with edit access to [email]”

The read-only servers handle research and analysis tasks well. The Google Cloud managed endpoint enables agentic workflows where Claude takes actions — organizing, creating, sharing — rather than just reading.

Which one should you use?

You are a developer working locally with Claude Desktop, need read-only access: Start with @modelcontextprotocol/server-gdrive. It is the reference implementation, gets the most community attention for bug fixes, and the read-only scope reduces risk. Follow the standard MCP setup for Claude Desktop.

You want a cleaner codebase or plan to extend the server: Start with felores/gdrive-mcp-server. More modular, MIT licensed, and better structured for modification.

You are setting up Claude Desktop for the first time and want the most thorough setup guide: michaelpine25/googleDriveMCP has the most step-by-step documentation aimed at getting someone from zero to working quickly.

You need write access, shared drive support, team deployment, or Claude.ai web compatibility: Google Cloud managed MCP is the only architecturally correct choice. Budget 30-60 minutes for GCP project setup and IAM configuration. The complexity is upfront, not ongoing.

You are in an enterprise environment with security requirements: Google Cloud managed MCP is the only option with IAM-level access control, centralized audit logging, and organization policy enforcement. None of the community implementations support this.

FAQ

Can I use a Google Drive MCP server with Claude.ai on the web?

Not with the community stdio servers. Claude.ai requires remote MCP endpoints over HTTPS. Only the Google Cloud managed MCP endpoint works with Claude.ai web. Community servers only work with Claude Desktop (local stdio transport).

Do I need a GCP project for the community servers?

Yes, but only to create OAuth credentials. You do not need to pay for or configure GCP services beyond enabling the Drive API and creating OAuth 2.0 credentials in the free Google Cloud Console. The GCP project for Google Cloud managed MCP is a heavier dependency — you need it for IAM, billing, and the managed endpoints themselves.

Is my Drive data sent to Anthropic?

When you use an MCP server with Claude, the file content retrieved by the server is included in the context window that Claude processes. This means file content is sent to Anthropic’s API as part of the conversation. Review Anthropic’s data processing terms if this is a concern for sensitive documents.

Can I limit which files the MCP server can access?

With the community servers using drive.readonly, the server can access any file in your Drive that your Google account can access. There is currently no built-in file-level restriction in the community implementations. With Google Cloud managed MCP and drive.file scope, you can limit access to only files the app has opened or created. For more granular control, a service account with domain-wide delegation allows access to only specific users’ files in a Workspace organization.

What happens to my token.json if Claude Desktop crashes mid-session?

The refresh token in token.json remains valid until you revoke it in Google Account settings or until the OAuth app is deleted from Google Cloud Console. A crash does not revoke credentials.

Can these servers access shared drives (Team Drives)?

Community implementations do not explicitly handle the supportsAllDrives and includeItemsFromAllDrives Drive API parameters required for shared drive access. In practice this means files in shared drives may not appear in search results or may return permission errors. Google Cloud managed MCP explicitly supports shared drives.

Where to find these servers on MyMCPShelf

We have listed the key Google Drive MCP implementations in our directory. You can find them in the Knowledge & RAG category and the Productivity category. Each listing includes the GitHub link, transport type, and our curation notes on setup complexity.

If you are evaluating the Google Workspace angle more broadly, also check our listings for the Google Calendar MCP server and Gmail MCP server — the Google Cloud managed stack covers all of these under a unified IAM model.

The MCP ecosystem around Google Drive is moving fast. The official Anthropic reference server will likely gain write capabilities as the protocol matures. Google’s managed endpoint is expanding Workspace coverage monthly. If you are making infrastructure decisions today, lean toward the architecture that will not require a rebuild when capabilities expand — which for teams means the Google Cloud managed approach, and for individual developers means starting with the reference server and watching the monorepo for updates.