The shortcut that puts a whole team on one Google account
The fast way to get a team's spreadsheets and documents into Claude is for one person to connect Google Drive and share that connection. It works, and it is the wrong shape. Every call through a connection runs on the account it was connected with, whoever is asking. A toolbox shared with a team runs each entry on the connection pinned in it. The authority is the person who pinned that entry.
So Google Sheets MCP access for Claude starts with a sharing decision, before any restriction. Tools that run on each person's own account come from each person's own connections. That means their All tools toolbox, or a toolbox they build on their own connections. It can also be a template each person stamps, picking their own connection for each app. One connection shared with eight people answers eight people's questions from one person's Drive.
That matters more in Drive than almost anywhere else. A Google account's reach is whatever that person can open, and most of the files a team cares about are shared unevenly. The same trap shows up with other file stores. Keeping Box per person in Claude walks through it with a different vendor's permission model.
How do you set up Google Sheets MCP access for Claude?
Five steps, in this order. Elaichi serves MCP at one address, https://api.elaichi.ai/mcp, and Claude, ChatGPT and Cursor all sign into the same one. MCP is the protocol an AI client uses to find and run tools.
- Add Elaichi in Claude once. On Claude Team and Enterprise, an Owner or Primary Owner adds the custom connector. In Organization settings > Connectors, click Add, hover over Custom and choose Web (support.claude.com, checked October 2026). Each member then finds it under Customize > Connectors and clicks Connect. The step-by-step walkthrough lives in connecting Elaichi to Claude.
- Each member approves their own grant. On Elaichi's consent screen they pick the organization and tick "Run your connected tools". That grant is what decides which person and which organization Claude reaches, not the URL.
- Each member connects their own Google account. Creating a personal connection is a default Member permission, so nobody needs an admin for this.
- Build one template, not one connection. A template is a named list of tool entries and stores no connection. Share it at use, and each teammate stamps it with "Use this template", choosing their own Google connection for each connector. An entry they skip shows "Needs connection" until one is pinned.
- Narrow the grant if you want to. At consent, "Only the ones I pick" limits the client to named toolboxes, re-checked on every call. "All my tools" reaches everything that person can run, including accounts they add later.
In the client's tool list, connected tools are never listed one by one, however few there are. Claude finds a Drive tool with search_tools and runs it with execute_tool.
Which Google connectors the catalog actually has
Google Workspace is covered in Elaichi's catalog by separate connectors: gmail, googledrive, googlecalendar and googledocs. A spreadsheet and a document are both Drive files. The googledrive connector reads files, folders, shared drives, drive items, search and export. It also reads permissions, labels, revisions, comments and replies, Docs, Forms and the change log. Tools such as list_all_googledrive_files, list_all_googledrive_search and get_single_googledrive_file_by_id do that work.
The connector carries 28 tools: 25 reads and three that are not. None of the 28 creates, edits, shares, moves or deletes a file. If a team needs cell-level spreadsheet work the catalog does not cover, an organization on Gold can add a remote MCP server as its own connector. An Org Owner or Org Admin creates it. The same restrictions, scopes and audit log apply.
One setup note. Where a connector needs your organization's own Google OAuth app, its page in Elaichi shows an OAuth application card. An admin with the Manage connectors permission stores the client id and secret there. The Scopes box starts blank and never pre-fills Elaichi's defaults; a typed list replaces them wholesale, so it has to be complete. Google treats drive and drive.readonly as restricted scopes that need its verification. An exception applies for internal use within one Workspace or Cloud Identity organization (developers.google.com, checked October 2026).
Two restrictions that keep Drive reads from becoming Drive writes
Write two block rules. A restriction in Elaichi says which connectors and tools a role or one member may reach. It is checked before the call leaves Elaichi.
Rule one: block the three non-read Drive tools. They are create_a_googledrive_watch, create_a_googledrive_changes_watch and delete_a_googledrive_channel_by_id. The first two ask Google to post change notifications to an HTTPS address the caller supplies; the third stops a channel. Nobody asking what changed in a folder needs them. A model that hands Google an address is not a conversation you want to have afterwards.
Rule two: keep Drive and Docs off the roles that should not have them. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So the rule goes on each role that should not reach the connector. Use block rules for this. An allow rule turns on an allowlist for the whole role the moment it exists, across every connector. A role on allow rules therefore needs one for each other app it uses.
Consider another rule where sharing audits are not the team's job: block list_all_googledrive_permissions, which reads who a file is shared with.
Two mechanics to know. A block rule matches by tool name or by the operation the tool performs. Renaming a tool does not slip it past a block. An allow rule matches only the operation pinned when the rule was saved. A restriction change reaches every surface within about two minutes.
This layer is the one that holds. The consent checkbox "Run your connected tools" covers every tier of connected tool, writes included. "Delete data and remove access" only covers Elaichi's own deletes. In Claude, every connected-tool call arrives as execute_tool, so a per-tool permission in Claude cannot tell Drive from any other app. Per-app control is set in Elaichi. The trade-offs between those two shapes are laid out in restricting one tool or a whole app.
What a restriction cannot reach: Google decides what each account sees
Restrictions bind connectors and tools. They do not bind folders, and nothing in Elaichi makes a Google account see less than it already sees.
That limit is Google's, not a gap in any one product. Google documents no Drive API scope that limits an app to a single folder. The narrowest scopes it lists grant per-file access (developers.google.com, checked October 2026). A files.list folder query is a filter on which of the user's files come back, not an access control (developers.google.com, checked October 2026).
So scope it in Google. Put the team's spreadsheets and documents in a shared drive. Set Drive sharing per organizational unit or configuration group. Google says its admin sharing settings give admins no control over individual folders in users' My Drives (knowledge.workspace.google.com, checked October 2026). The folder and people variants are covered in scoping Google Drive in Claude.
One more honest note on locked-in values. If an entry's tool takes a drive or folder argument, a toolbox entry can freeze it. The AI client cannot change it on the call. The freeze holds only on calls through that entry. Anyone who can use the connection has the same tool unfrozen in their All tools toolbox. Treat a freeze as a default that travels with the toolbox, not as a boundary.
The audit query that proves the rollout
One filter: open the organization's audit log, set the category to Assistant, pick Last 30 days, and search googledrive.
Connected-tool calls sit in the Assistant category, because their action is assistant.toolbox_tool. Filtering to MCP shows client grants instead. Free-text search matches each word against the action, resource type, resource id, acting user id and the event's metadata. A connected-tool row records the tool's advertised and catalog names. Searching the connector slug therefore returns every Drive call.
Read three things off each row. The Connection line names the account the call actually reached, which is how you prove nobody is riding on one person's Drive. The "What it did" line reads Read data, Changed data or Deleted data; in this rollout every Drive row should read Read data. The summary sentence opens with where the call ran, for example "Using Claude,", and names the person, the item and the connection.
Two caveats a reviewer will ask about. The log records what ran. A tool a restriction withholds is left out of the client's tool list, and writes no row when it is refused. The evidence that the rule exists is the restriction.created and restriction.updated entries, not an absence. And Elaichi keeps 90 days of audit history; the console's All time range covers at most the last 400 days. Reading the whole organization's log needs the View audit log permission, held by Org Owner, Org Admin and the free Auditor role. Everyone else sees their own events plus events on connections they own or can edit. Export the filtered view as CSV, up to 10,000 entries. The full field list is in what an AI agent audit log must capture.
When one Claude connector is enough
If this is one team, one app and nobody is asking for evidence, do not add a second vendor. Anthropic's Google Workspace connectors are available on every Claude plan, and Google builds and runs the Drive connector. Each person signs in with their own Google account, and Claude mirrors that account's Workspace permissions (support.claude.com, checked October 2026). On Team and Enterprise an Owner can set a connector's tools to Always allow, Needs approval or Blocked. Anthropic's own example allows Drive reads while preventing document creation or editing (support.claude.com, checked October 2026). That covers a single-app read-only rollout without anything else in the path.
The case for one governed endpoint starts when there are several apps and several roles. The same rules, the same audit log and the same offboarding then have to cover Drive, the CRM and the ticket queue at once. Browse what is already in the connector catalog, or see how toolboxes carry one team's tools.
