# Google Sheets MCP access for Claude, team-wide

> Google Sheets MCP access for Claude, team-wide: each person signs in with their own Google account, and two block rules keep Drive reads from writes.

**TL;DR** To connect Google Sheets and Docs to Claude for the whole team, each member connects their own Google account in Elaichi and approves their own grant. Every call then runs with that person's Google permissions. Two block rules on each role keep the Drive connector to reads. One filter on Elaichi's audit log shows who ran which Drive tool through which account. Folder-level scoping is not something a restriction can do. Set that boundary in Google, with a shared drive and Drive sharing settings.

## 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.

1. **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](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), 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](/blog/connect-elaichi-to-claude/).
2. **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.
3. **Each member connects their own Google account.** Creating a personal connection is a default Member permission, so nobody needs an admin for this.
4. **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.
5. **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](/connectors/googledrive/) 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](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification), 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](/blog/per-tool-vs-per-app-restrictions/).

## 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](https://developers.google.com/workspace/drive/api/guides/api-specific-auth), 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](https://developers.google.com/workspace/drive/api/guides/search-files), 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](https://knowledge.workspace.google.com/admin/drive/manage-external-sharing-for-your-organization), checked October 2026). The folder and people variants are covered in [scoping Google Drive in Claude](/blog/claude-google-drive-sharing-permissions/).

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](/blog/what-an-ai-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](https://support.claude.com/en/articles/10166901-use-google-workspace-connectors), 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](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities), 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](/connectors/), or see how [toolboxes](/use-cases/toolboxes/) carry one team's tools.

## FAQ

### Does Elaichi have a Google Sheets connector?

Google Workspace is covered in Elaichi's catalog by separate connectors: gmail, googledrive, googlecalendar and googledocs. A spreadsheet is a Drive file. The googledrive connector's read tools cover files, folders, shared drives, search, export, revisions, comments and the change log. A team that needs spreadsheet work the catalog connectors do not cover can add a remote MCP server as its own connector, on the Gold plan. An Org Owner or Org Admin creates it, and the same restrictions, scopes and audit log apply.

### Can Claude edit or delete a Google Drive file through Elaichi?

No. Elaichi's googledrive connector carries 28 tools, and none of them creates, edits, shares, moves or deletes a file. Its three non-read tools manage Google change-notification channels. Two ask Google to post notifications to an HTTPS address the caller supplies, and one stops a channel. Blocking those three for each role leaves the connector reading only.

### Can a restriction limit Claude to one Google Drive folder?

No. Restrictions in Elaichi bind connectors and tools, not folders. Google documents no Drive API scope that limits an app to a single folder. The narrowest scopes it lists grant per-file access (checked October 2026, https://developers.google.com/workspace/drive/api/guides/api-specific-auth). A folder query on a list call is a filter on which of the user's files come back, not an access control. Set that boundary in Google instead, with a shared drive and Drive sharing settings per organizational unit or group.

### How quickly does a new restriction apply to someone's AI client?

A role, team, restriction or access-grant change in Elaichi reaches every surface within about two minutes. Some changes are faster. Revoking a share or disconnecting a connected account takes effect on the caller's next call. So does disconnecting an AI client's grant, because Elaichi re-reads the grant on every MCP request.

### Where do Google Drive calls from Claude appear in the audit log?

They appear in the Assistant category of Elaichi's audit log, because a connected-tool call is recorded with the action assistant.toolbox_tool. Each row records the person, the tool's advertised and catalog names, the connector and the connection the call actually reached. It also records whether approval was required, the surface it came from and the MCP client's id. Filtering the log to the MCP category shows client grants rather than tool calls.

## Read next

- [Slack MCP access for ChatGPT: a safe company rollout](/blog/connect-slack-to-chatgpt-for-the-whole-company-safely/) — Two restrictions, one guard you do not configure, and one audit query: Slack MCP access for ChatGPT, rolled out company-wide.
- [Connect Ashby to ChatGPT for recruiters](/blog/connect-ashby-to-chatgpt-for-recruiters/) — Connect Ashby to ChatGPT for recruiters with two restriction rules that hold the role to reads, plus the audit query that proves nothing was changed.
- [Connect Linear to Claude for our product team](/blog/connect-linear-to-claude-for-our-product-team/) — To connect Linear to Claude for our product team, govern Linear's own MCP server: per-person sign-in, a block rule, review for new tools.