mcp-google-sheets: an MCP server that puts Google Sheets behind 19 tool calls
This MCP server integrates with your Google Drive and Google Sheets, to enable creating and modifying spreadsheets.
At a glance
- What is it?
- xing5/mcp-google-sheets is a Python MCP server that exposes Google Drive and Sheets operations as tools an MCP client can call. It is MIT-licensed, ships as a PyPI package runnable through uvx, and its main design tension is context budget: all 19 tools cost roughly 13K tokens unless you filter them.
- Who is it for?
- Adopt mcp-google-sheets if you already run an MCP client, you can create a Google Cloud service account, and you are willing to pin the package version and pass --include-tools or ENABLED_TOOLS to keep the tool list small. Do not adopt it if you need a stand-alone Sheets CLI, a library you import directly, or an audited data pipeline: this is a bridge for an assistant, not an ETL tool.
- 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 124 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap it fills: an assistant that can actually touch a spreadsheet
An MCP client can reason about tabular data, but it cannot read or write a Google Sheet unless something exposes those operations as tools. That is the entire job of this project. The README describes it as a bridge between any MCP-compatible client, Claude Desktop being the named example, and the Google Sheets API, with a defined set of tools that make spreadsheet interaction possible from natural language.
The audience is narrow and specific. You need an MCP client already configured, a Google Cloud project where the Drive and Sheets APIs are enabled, and a credential the server can use. If you have none of those, this package gives you nothing. If you have all three, it removes the step where a human copies data out of a sheet and pastes it into a chat window. The repository topics (google, mcp, mcp-server, spreadsheet) and the Python implementation match that scope; there is no separate CLI or importable library advertised.
Architecture: one process, a fixed tool surface, Google APIs behind it
The server is a Python process that authenticates to Google and registers a set of named tools. The README lists the full surface: add_columns, add_rows, batch_update, batch_update_cells, copy_sheet, create_sheet, create_spreadsheet, find_in_spreadsheet, get_multiple_sheet_data, get_multiple_spreadsheet_summary, get_sheet_data, get_sheet_formulas, list_folders, list_sheets, list_spreadsheets, rename_sheet, search_spreadsheets, share, and update_cells. That is 19 tools, and the README states they consume roughly 13,000 tokens before any conversation begins.
The data flow is request-response in both directions. The client sends a tool call; the server translates it into a Drive or Sheets API request; the response goes back as tool output. Nothing in the supplied material suggests the server keeps its own copy of sheet data between calls, so each operation is effectively stateless from the client's point of view. The batching tools (batch_update, batch_update_cells, get_multiple_sheet_data, get_multiple_spreadsheet_summary) exist because a chat turn that touches many cells one call at a time is slow and expensive in tokens. That grouping is the practical reason those tools are in the list.
A second architectural decision sits in the auth layer rather than the tool layer: the server can take credentials three ways, per the README, a service account file, OAuth 2.0, or direct credential injection through an environment variable. Which one you pick changes what the server can see, because a service account sees only what has been shared with it, while OAuth acts as the authorizing user.
Getting it running: uvx, two environment variables, one JSON block
The README's quick start is deliberately short. Install uv (the README gives curl -LsSf https://astral.sh/uv/install.sh | sh for macOS and Linux, a PowerShell one-liner for Windows, or pip install uv), then run the server with uvx mcp-google-sheets@latest. The README recommends always using @latest and warns that without it uvx may use a cached older version. That warning is worth taking literally: it means your effective version is a function of your local cache, not of a lockfile.
Before the server will do anything useful, two environment variables are set. SERVICE_ACCOUNT_PATH points at the service account JSON key, and DRIVE_FOLDER_ID names the folder the server works against. The README shows export syntax for Linux and macOS, set for Windows CMD, and $env: for PowerShell. A service account is described as the recommended path, with OAuth and a CREDENTIAL_CONFIG option mentioned as alternatives.
Client configuration is a standard MCP server block. The README's example uses command uvx with args ["mcp-google-sheets@latest"], and the env object carrying SERVICE_ACCOUNT_PATH. The same block shows the filtering flag in place: args become ["mcp-google-sheets@latest", "--include-tools", "get_sheet_data,update_cells,list_spreadsheets,list_sheets"]. The equivalent environment variable is ENABLED_TOOLS, holding the same comma-separated list with no spaces. Both forms are documented; pick one and keep it in version control, because a tool name typo will silently narrow or break the surface your client sees.
Tool filtering is the feature that decides whether this is usable
The README frames tool filtering as a solution to a stated problem: all 19 tools consume about 13,000 tokens of context before the conversation starts. For a client with a modest context window, or for a session where the user only wants to read one range, that overhead is real. The README's recommended subset is four tools: get_sheet_data, update_cells, list_spreadsheets, list_sheets. Those four cover reading, writing, finding a spreadsheet, and navigating its tabs.
The trade-off is blunt. Filtering to four tools means create_spreadsheet, share, and the batch operations are unavailable, and the client has no way to discover them at runtime. If a user asks the assistant to create a new spreadsheet while the filter excludes create_spreadsheet, the request fails at the tool layer, not in a graceful way. The README does not describe a runtime mechanism for adding a tool back without restarting the server with a different flag. So the filtering decision is a deployment decision, and it should match the actual job the assistant is doing. A read-only reporting assistant and a spreadsheet-building assistant want different lists.
One gap in the documentation: the README lists the tool names but, in the supplied text, does not give a per-tool parameter schema or return shape. Anyone wiring this into an automated flow will need to read the source or the client's tool introspection to learn what arguments each tool expects.
Where it breaks: credentials, scope, and the wrong-tool cases
The most likely failure is not in the code but in Google Cloud. The README states plainly that you must configure Google Cloud Platform credentials and enable the necessary APIs first, and it points to a detailed setup section. A service account is a separate identity: creating the key file is not enough, the target spreadsheet or folder has to be shared with that service account's address. The README's DRIVE_FOLDER_ID variable suggests the intended pattern is a folder shared with the service account, with spreadsheets created inside it. A sheet that lives elsewhere and was never shared will not appear in list_spreadsheets, and the failure will look like an empty result rather than an error.
There are also cases where this is simply the wrong tool. If you need a scheduled job that appends rows to a sheet every hour, an MCP server is an odd fit: it is built to be driven by a conversational client, and the README's deployment story is uvx plus a client config. A small script using the Google client libraries directly would be easier to schedule, test, and log. Similarly, if you need transactional guarantees across many sheets, or you need to know exactly which cells changed and when, the tool surface here does not advertise that. The batch tools reduce round trips; they are not described as atomic transactions.
Finally, the authentication choice carries a scope consequence the README does not resolve for you. A service account is recommended, but it cannot act as an end user, so anything requiring the user's own Drive permissions has to go through the OAuth path instead. That is a deployment decision with security weight, and the README leaves the comparison to the reader.
The alternative worth comparing: calling the Google APIs without an MCP layer
The obvious alternative is not another MCP server; it is skipping MCP entirely and using the Google Sheets and Drive client libraries from a script or service. The difference in approach is who holds the tool definitions. With mcp-google-sheets, the tool list is fixed at 19 names, the client discovers them, and the model chooses among them in natural language. With a direct integration, you write the functions your application needs (read a range, append a row, create a tab), you control retries and error handling, and there is no 13K-token tool preamble because nothing is being described to a model.
That matters when the workflow is known in advance. A nightly export does not benefit from a model deciding which of 19 tools to call. The MCP server earns its place when the workflow is not known in advance, that is, when a person is asking ad hoc questions and the set of operations varies per turn. The README's own framing supports this reading: the tools are described as enabling natural language spreadsheet interaction for MCP-compatible clients, not as a general automation framework.
A second, narrower alternative is to keep MCP but use a different server that covers a different surface. The supplied material does not name one, so the honest comparison is the direct-API route, where the cost is code you maintain and the benefit is explicit control over every call.
Maintenance, versioning, and what the MIT licence does and does not settle
The release history supplied here shows v0.6.1 in March 2026, then v0.6.2 and v0.6.3 on the same day in May 2026, with the repository's last push matching the v0.6.3 timestamp. Two patch releases within minutes of each other usually means a fix landed and was immediately corrected; the material does not say which. The practical consequence for an operator is that this package moves in small increments and the README's advice to run @latest means your deployment tracks those increments automatically unless you pin.
Pinning is the cheaper option. Because the README documents both a CLI flag and an environment variable for tool selection, the version string in your MCP client config is the only other moving part. Fixing it at a specific version such as mcp-google-sheets@0.6.3 trades automatic fixes for reproducibility, and the README's own warning about uvx caching makes that trade more attractive, not less.
The project is MIT-licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. That covers the server code. It does not cover your Google Cloud usage: API quotas, billing, and the terms attached to the service account remain between you and Google, and the supplied material says nothing about them. The licence also says nothing about the data the server touches, which lives in your Drive under whatever sharing rules you configured. Nothing here is legal advice; if the spreadsheet holds regulated data, the licence question is the smaller one.
Editorial conclusion
Adopt mcp-google-sheets if you already run an MCP client, you can create a Google Cloud service account, and you are willing to pin the package version and pass --include-tools or ENABLED_TOOLS to keep the tool list small. Do not adopt it if you need a stand-alone Sheets CLI, a library you import directly, or an audited data pipeline: this is a bridge for an assistant, not an ETL tool. Before trusting it with a real spreadsheet, verify three things: that the service account has been granted access to the target spreadsheet or folder, that the four tool names you pass to --include-tools are spelled exactly as the README lists them, and that uvx mcp-google-sheets@latest resolves to the version you expect, because the README warns that without @latest uvx may run a cached older build.
Community notes