Model or dataset
xing5/mcp-google-sheets avatar
xing5/mcp-google-sheets

mcp-google-sheets: an MCP server that gives AI clients read and write access to Google Sheets

This MCP server integrates with your Google Drive and Google Sheets, to enable creating and modifying spreadsheets.

1,010 stars252 forksPythonMIT

At a glance

What is it?
xing5/mcp-google-sheets is a Python MCP server that brokers Google Drive and Google Sheets API calls for MCP-compatible clients. It is easy to launch with uvx, but you still have to do the Google Cloud credential work yourself.
Who is it for?
Adopt mcp-google-sheets if you already run an MCP client and want spreadsheet reads and writes driven from it, and if you are willing to set up a Google Cloud service account and share the target files with it. Do not adopt it if you need Docs or Gmail coverage, if you cannot hand a service account access to the Drive folder, or if you want a hosted product with no credential work.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 138 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What mcp-google-sheets solves, and who it is for

An MCP client can call tools, but it cannot reach Google's APIs on its own. The README describes mcp-google-sheets as a bridge between an MCP-compatible client and the Google Sheets API, exposing spreadsheet operations as a defined tool set so a model can create, read and modify spreadsheets through natural language. The intended user is someone who already runs a client such as Claude Desktop and wants that client to touch real spreadsheets rather than pasted text. It is not a spreadsheet product. It is a process that translates tool calls into Google API requests, and the quality of the result depends on the credentials you attach to it. The repository is not archived, and the most recent push was on 2026-05-14, so the codebase has moved recently enough that the README's tool list is worth checking against your installed version.

How the server talks to Drive and Sheets

The project is a Python package, published on PyPI, whose console entry point is mcp-google-sheets, defined in pyproject.toml. It depends on mcp, google-auth, google-auth-oauthlib and google-api-python-client, so the actual API calls go through Google's official Python client libraries rather than hand-rolled HTTP. Authentication is resolved from the environment: the README's quick start uses SERVICE_ACCOUNT_PATH pointing at a service account key file, and DRIVE_FOLDER_ID naming the folder the server should work inside. OAuth 2.0 and direct credential injection through CREDENTIALS_CONFIG are listed as alternatives. The server exposes 19 tools by default, which the README says costs roughly 13,000 tokens of context before any conversation starts. That number is the project's own estimate, not a measured benchmark. The Dockerfile builds a wheel with uv, installs it, and starts the server with --transport sse, so the same code can run as a local stdio process or as an SSE service.

Installing mcp-google-sheets with uvx and connecting a client

The README's recommended path avoids a manual install. Install uv first, then let uvx fetch and run the package. On macOS or Linux the installer is a shell script:

bash
curl -LsSf https://astral.sh/uv/install.sh | sh

On Windows the README gives a PowerShell equivalent:

powershell
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

Then export the two variables the service account path needs. The README warns to use your own key path and folder ID:

bash
export SERVICE_ACCOUNT_PATH="/path/to/your/service-account-key.json"
export DRIVE_FOLDER_ID="YOUR_DRIVE_FOLDER_ID"

Run the server directly to confirm it starts and prints its ready log:

bash
uvx mcp-google-sheets@latest

The README recommends always passing @latest, because without it uvx may reuse a cached older version. For a client, the configuration is a command, arguments and environment block. This example enables only four tools, which is the filtering mechanism described below:

json
{
  "mcpServers": {
    "google-sheets": {
      "command": "uvx",
      "args": [
        "mcp-google-sheets@latest",
        "--include-tools",
        "get_sheet_data,update_cells,list_spreadsheets,list_sheets"
      ],
      "env": {
        "SERVICE_ACCOUNT_PATH": "/path/to/credentials.json"
      }
    }
  }
}

After the client restarts you should see the four named tools available. If the server exits immediately, the usual cause is a credential path that does not resolve.

Tool filtering is the feature that matters most in daily use

Nineteen tools at roughly 13K tokens is a real cost for anyone running a long conversation. The README treats this as the problem tool filtering exists to solve, and offers two equivalent switches: the --include-tools command-line argument, or the ENABLED_TOOLS environment variable. Both take a comma-separated list with no spaces, and the names must match exactly. The README recommends a common subset of get_sheet_data, update_cells, list_spreadsheets and list_sheets, which covers reading, writing, finding files and navigating tabs. The full list includes batch_update, batch_update_cells, get_multiple_sheet_data, get_sheet_formulas, create_spreadsheet, create_sheet, copy_sheet, rename_sheet, add_rows, add_columns, find_in_spreadsheet, search_spreadsheets and list_folders. The trade-off is obvious: filter too aggressively and the client will simply not have the tool it needs, with no partial fallback. Note that the README's tool list is truncated in places, so confirm the exact spelling of any name you filter on against your installed version rather than assuming.

Where mcp-google-sheets is the wrong tool

The scope is Sheets and Drive. The README's related-topic tags mention Google Docs and Google Workspace, but the tool list contains no document, mail or calendar operations, so a request to edit a Doc will not be served by this server. The heavier constraint is authentication. The README states you must configure Google Cloud Platform credentials and enable the necessary APIs before anything works, and it recommends a service account. That means the spreadsheet must be shared with the service account's address, and the server's view of Drive is bounded by what that account can see. On a personal Google account where sharing a folder with a robot identity is awkward or against policy, OAuth is the alternative, but the README does not document the token refresh lifecycle in the excerpt available, so plan for that as an open question rather than a solved one. There is also no documented rollback or undo tool. A bad batch_update is a bad batch_update, and recovery means using Sheets' own version history.

How it compares with the Google Workspace MCP route

The most direct alternative is a Workspace-wide MCP server that covers Docs, Drive, Gmail and Calendar behind one credential setup. The difference in approach is breadth against setup cost. A Workspace-wide server gives you one OAuth consent and one process for several Google products, which is convenient if you need Docs alongside Sheets. mcp-google-sheets narrows to spreadsheets and the Drive operations around them, and its tool surface is correspondingly small and predictable, which makes the context budget easier to reason about. If your work is entirely tabular, the narrower server is the simpler thing to configure and filter. If you need to move data between a Doc and a Sheet, a Workspace-wide server avoids running two processes with two credential configurations. Neither approach removes the Google Cloud project setup; they only change how much of it you do at once.

Maintenance, licence and upgrade cost

The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is a permissive arrangement, but it says nothing about the Google APIs the server calls, which carry their own quotas and terms that you accept separately. On maintenance: the repository is not archived, and the last push was on 2026-05-14, with releases v0.6.1 on 2026-03-15, v0.6.2 on 2026-05-14 and v0.6.3 on 2026-05-14. There is a TODO_STATUS.md at the repository root, which suggests the author tracks outstanding work in-tree, though its contents are not in the available repository files. Upgrading is cheap by design: because the README recommends pinning to @latest, a restart picks up the newest release, and there is no migration step documented between v0.6.x versions. The cost of that convenience is that an upstream change can alter tool behaviour without any action on your part, so pinning a specific version is the safer choice for anything you depend on.

Editorial conclusion

Adopt mcp-google-sheets if you already run an MCP client and want spreadsheet reads and writes driven from it, and if you are willing to set up a Google Cloud service account and share the target files with it. Do not adopt it if you need Docs or Gmail coverage, if you cannot hand a service account access to the Drive folder, or if you want a hosted product with no credential work. Before rolling it out, verify that the service account has been granted access to the folder named by DRIVE_FOLDER_ID, and check the tool list in the README against the operations you actually need.

Frequently asked questions

Is there an MCP for Google Sheets?

Yes. mcp-google-sheets is a Python MCP server that connects an MCP-compatible client to the Google Sheets API, exposing spreadsheet operations as tools. It runs as a local process launched by the client, or as an SSE service via the Docker image.

Does Google have an MCP?

The repository describes mcp-google-sheets as a third-party project by Xing Wu, published on PyPI under the MIT licence, not an official Google product. It uses Google's own Python client libraries to call the Sheets and Drive APIs.

Can you use Google Sheets as an API?

mcp-google-sheets does exactly that in practice: it wraps the Google Sheets API behind MCP tools such as get_sheet_data and update_cells, so a client can read and write cells without calling the REST API directly. You still need Google Cloud credentials and the relevant APIs enabled.

Is there an AI agent for Google Sheets?

mcp-google-sheets is not an agent on its own; it is the tool layer an agent uses. Any MCP-compatible client connected to it can create, read and modify spreadsheets through the exposed tools.

Official sources

  1. Issues
  2. License: MIT
  3. README
  4. Releases
  5. xing5/mcp-google-sheets on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/xing5-mcp-google-sheets.svg)](https://hysenlabs.com/projects/xing5-mcp-google-sheets)