Which integrations are available for this server?

Provides read/write access to Google Spreadsheets, enabling AI agents to manage sheets, rows, columns, and cell data programmatically.

How do I use MCP Google Sheets?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Google Sheets add a row for new user to the users sheet" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP Google Sheets

by toantran201

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP Google Sheets

An MCP (Model Context Protocol) server that gives AI agents read/write access to Google Spreadsheets. Built for use with Claude Code and other MCP-compatible clients.

Features

9 tools for spreadsheet interaction — read metadata, read cells, extract schemas, create/rename tabs, append rows, insert columns, set column validation, update rows
Per-user OAuth (recommended) — each user signs in with their own Google account; sheet edit history shows who actually made each change
Service Account auth (legacy) — fully headless, no OAuth popups
No fixed spreadsheet — every tool takes a spreadsheet parameter (paste a Sheets URL or ID); any sheet the signed-in user can edit just works
Tool filtering — expose only the tools you need via the TOOLS variable
Audit trail — optionally stamp each written row with a user name

Related MCP server: google-sheets-mcp

Available Tools

Every tool takes a required spreadsheet parameter: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID.

Tool	Description
`get_spreadsheet_info`	Returns spreadsheet title, sheet names, IDs, and dimensions
`get_sheet_schema`	Returns column schema: dropdowns, checkboxes, data types, formulas, notes
`get_sheet_data`	Reads cell values from a range (e.g. `Sheet1!A1:D10`)
`find_rows`	Finds rows matching a value in a column (or any column); returns 1-based row indices
`create_sheet`	Creates a new sheet tab
`rename_sheet`	Renames a sheet tab (by ID or current name)
`add_rows`	Appends rows to the bottom of a sheet
`add_columns`	Inserts empty columns at a 1-based position, or appends at the right edge
`update_row`	Overwrites cells in a row starting at a 1-based column (update specific columns without rewriting the whole row)
`delete_rows`	Deletes a contiguous block of rows (rows below shift up)

Install

If you use Claude Code, add the server with one command. You need an OAuth Client ID and Client Secret — ask whoever set up your team's Google Cloud project, or create them yourself via OAuth Setup below.

claude mcp add \
  --scope user \
  --env GOOGLE_OAUTH_CLIENT_ID=<your-client-id>.apps.googleusercontent.com \
  --env GOOGLE_OAUTH_CLIENT_SECRET=<your-client-secret> \
  --transport stdio \
  google-sheets \
  -- npx -y @toantran201/mcp-google-sheets

On Windows PowerShell, put it on a single line (drop the \ line breaks), or replace \ with a backtick `.

--scope user makes the server available in all your projects. Use --scope project instead to write it into a shared .mcp.json (checked into the repo for your whole team), or omit --scope for the current project only.
--transport stdio is the default; it's shown here mainly so the server name doesn't sit directly after --env (the CLI rejects that).

That's it. On the first tool call, your browser opens for Google sign-in; your personal token is cached at ~/.google-sheets-mcp/tokens.json. There is no fixed spreadsheet — just paste a Google Sheets URL into the conversation.

Add this to your .mcp.json (Claude Code) or your client's MCP config:

{
  "mcpServers": {
    "google-sheets": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@toantran201/mcp-google-sheets"],
      "env": {
        "GOOGLE_OAUTH_CLIENT_ID": "xxxxx.apps.googleusercontent.com",
        "GOOGLE_OAUTH_CLIENT_SECRET": "GOCSPX-xxxxx"
      }
    }
  }
}

Optional env keys: TOOLS (comma-separated allowlist, blank = all — see Restricting Tools), USER_NAME (stamped onto add_rows writes). Pin a version with @toantran201/mcp-google-sheets@1.2.3.

Prerequisites

Node.js 20+ (only needed locally; npx handles it automatically)
A Google Cloud project with the Sheets API enabled
OAuth client credentials (recommended) or a Google Service Account

OAuth Setup (recommended — one-time, per team)

With OAuth, each team member authenticates with their own Google account. Edits show up under their name in the sheet's version history, and they can access any sheet they already have permission on — no sharing to a robot account needed.

1. Create a Google Cloud Project

Go to Google Cloud Console
Click the project dropdown at the top and select New Project
Give it a name (e.g. mcp-sheets) and click Create

2. Enable the Google Sheets API

Go to APIs & Services > Library
Find Google Sheets API and click Enable

Go to APIs & Services > OAuth consent screen
Choose the user type:
- Internal (available if your team uses Google Workspace) — recommended. No verification needed, refresh tokens never expire, and only members of your organization can sign in.
- External — works with any Google account, but while the app is in Testing status you must add each teammate as a test user, and refresh tokens expire every 7 days (the server detects this and simply re-opens the browser to sign in again).
Fill in the app name and contact emails, save

4. Create an OAuth Client ID

Go to APIs & Services > Credentials
Click + CREATE CREDENTIALS > OAuth client ID
Application type: Desktop app
Copy the Client ID and Client Secret. Supply them via your MCP client's env config — the --env flags in the Install command, or the env block in .mcp.json. (Only when developing locally do you put them in a .env file — see Local development.)

Per Google's documentation, a Desktop-app client secret is not treated as a confidential secret (installed apps can't keep secrets). It's fine to share it within your team, but keep it out of version control — don't commit a .env or a checked-in .mcp.json that contains it.

First run

The first time any tool is called, the server opens your browser for Google sign-in. After you approve, tokens are cached at ~/.google-sheets-mcp/tokens.json and later runs are silent. To switch Google accounts, delete that file.

Changing TOOLS from a read-only set to one that includes write tools requires a broader OAuth scope — the server detects this and re-prompts in the browser once.

Security notes

The sign-in flow uses the OAuth installed-app pattern with PKCE (S256) and a CSRF state check; the loopback server binds only to 127.0.0.1 on an ephemeral port.
The refresh token is cached in plaintext at ~/.google-sheets-mcp/tokens.json, protected by file permissions (0600, directory 0700; on Windows, your profile's NTFS ACLs). This is the same model used by gcloud and gh. Any process running as your OS user can read it — treat your user account as the trust boundary, and delete the file to revoke local access.
The OAuth client secret is never written to disk by the server; it comes from the environment your MCP client passes in (the env config), or from .env during local development.
All cell writes are sanitized against formula/CSV injection (leading =, +, -, @, tab, CR are neutralized with a ' prefix).

Service Account Setup (legacy alternative)

Headless auth with a shared robot account. Edits are attributed to the service account, not individual users, and every target sheet must be shared with it.

1. Create a Service Account

In your Google Cloud project (Sheets API enabled), go to APIs & Services > Credentials
Click + CREATE CREDENTIALS > Service account
Enter a name (e.g. mcp-agent) and click Create and Continue, then Done
Note the email address (e.g. mcp-agent@mcp-sheets.iam.gserviceaccount.com)

2. Generate a Private Key

Click on the service account, go to the Keys tab
Click Add Key > Create new key, select JSON, click Create
From the downloaded JSON: client_email → GOOGLE_SERVICE_ACCOUNT_EMAIL, private_key → GOOGLE_PRIVATE_KEY

Open the Google Sheet, click Share
Paste the service account email
Set the role to Editor (Viewer is enough for read-only tools)

Tip: The private key from the JSON file contains literal \n characters. Paste it as-is — the server handles the conversion.

Local development

Clone and install only if you want to modify the server:

git clone <repo-url>
cd google-sheets-mcp
npm install
cp .env.example .env   # fill in ONE auth mode below

# Mode A (recommended): per-user OAuth
GOOGLE_OAUTH_CLIENT_ID="xxxxx.apps.googleusercontent.com"
GOOGLE_OAUTH_CLIENT_SECRET="GOCSPX-xxxxx"

# Mode B (legacy): service account
# GOOGLE_SERVICE_ACCOUNT_EMAIL="mcp-agent@your-project.iam.gserviceaccount.com"
# GOOGLE_PRIVATE_KEY="-----BEGIN PRIVATE KEY-----\nMIIEv...\n-----END PRIVATE KEY-----\n"

# Optional — comma-separated list of tools to expose (blank = all)
TOOLS=""

# Optional — name appended to each row written by add_rows
USER_NAME=""

If both modes are configured, OAuth wins. There is no SPREADSHEET_ID — just paste a sheet link into your conversation and the agent passes it to the tools.

npm run dev      # run from TypeScript, no build
npm run build    # bundle to dist/index.js
npm start        # run the built server

Point .mcp.json at your local checkout while developing:

{
  "mcpServers": {
    "google-sheets": {
      "type": "stdio",
      "command": "npx",
      "args": ["tsx", "/absolute/path/to/google-sheets-mcp/src/index.ts"]
    }
  }
}

Publishing a new version

Maintainers only. The package is public on npm under the @toantran201 scope.

npm login                      # once per machine; sign in as the scope owner (toantran201)
npm version patch              # or minor / major — bumps package.json + git tag
npm publish                    # prepublishOnly runs the build automatically
git push --follow-tags

files in package.json limits the tarball to dist/ (plus README + LICENSE) — source, .env, and docs are never published. Verify with npm pack --dry-run before publishing.

Restricting Tools

Use the TOOLS environment variable to expose only specific tools. This reduces token usage when the agent doesn't need all capabilities, and in OAuth mode a read-only tool set requests the narrower read-only scope.

# Read-only mode
TOOLS=get_spreadsheet_info,get_sheet_data

# Write-only (no reads)
TOOLS=add_rows,update_row

# All tools (default)
TOOLS=

Project Structure

src/
  index.ts              Server bootstrap & stdio transport
  config.ts             Env var loading, auth-mode detection & validation
  sheets-client.ts      Google Sheets API wrapper (per-call spreadsheet ID)
  spreadsheet-ref.ts    Spreadsheet URL/ID parsing
  auth/
    auth-manager.ts     Auth entry point (OAuth or Service Account)
    oauth-flow.ts       Browser loopback sign-in flow
    token-store.ts      Per-user token cache (~/.google-sheets-mcp/)
    scopes.ts           Read-only vs read/write scope resolution
  tools/
    index.ts            Tool registry & TOOLS filter
    shared/             Non-tool helpers shared across tools
      types.ts          Shared ToolDefinition interface
      sanitize.ts       Formula-injection guard for cell writes
      result.ts         CallToolResult factory (success/error shapes)
    get-spreadsheet-info.ts
    get-sheet-schema.ts
    get-sheet-data.ts
    find-rows.ts
    create-sheet.ts
    rename-sheet.ts
    add-rows.ts
    add-columns.ts
    update-row.ts
    delete-rows.ts

License

MIT

Available Tools

10 tools

add_columnsAdd ColumnsA

Inserts empty columns into a sheet tab at a position, or appends them at the right edge.

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of empty columns to insert
`sheet_name`	Yes	Target sheet tab name
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID
`start_column`	No	1-based column index to insert BEFORE (e.g. 3 inserts before column C). Omit to append at the right edge of the sheet

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description should disclose side effects. It states the basic behavior (insert or append empty columns) but does not mention that inserting shifts existing columns to the right or any other impacts. The description is not misleading but lacks detail on data integrity or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the action and the two scenarios. Every word is necessary and there is no fluff. It is optimally concise for its complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (mutation, 4 parameters, no output schema, no annotations), the description adequately covers the core functionality of inserting or appending columns. It lacks details on error conditions or return values, but the schema covers parameter details. It is slightly above average in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it only repeats the insert/append concept. The schema already documents each parameter, including the optional start_column behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Inserts' and the resource 'empty columns into a sheet tab', and distinguishes between two modes: inserting at a specific position or appending at the right edge. This differentiates it from sibling tools like add_rows (which adds rows) and create_sheet (creates a whole sheet).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when you need to add empty columns to a sheet) and distinguishes the two insertion modes. However, it does not explicitly exclude alternatives or provide guidance on when not to use it. The purpose is clear enough for an agent to select it over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

add_rowsAdd RowsB

Appends rows to the bottom of a sheet tab.

ParametersJSON Schema

Name	Required	Description
`values`	Yes	2D array of rows to append
`sheet_name`	Yes	Target sheet tab name
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations present, so description must fully cover behavior. Only states 'appends rows to bottom' without disclosing if existing data is affected, permission requirements, error handling, or maximum row limits (though schema has some limits).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is very concise and front-loaded, but could include more detail without becoming verbose. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple but the description lacks usage context, behavioral details, and guidance for a user who might confuse it with update_row or find_rows. With no output schema or annotations, more description is warranted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the parameter names and descriptions already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Appends rows to the bottom of a sheet tab' clearly specifies the verb (appends), the resource (rows), and the location (bottom of sheet tab), distinguishing it from siblings like add_columns or update_row.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as find_rows with update, or insert vs append. No exclusions or prerequisites provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_sheetCreate SheetB

Creates a new sheet tab in the spreadsheet.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Name for the new sheet tab
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It only restates the action without disclosing behavioral traits such as whether it overwrites existing sheets, permissions required, or side effects. This is minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action. It is appropriately sized for a simple tool, though it could be more informative without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It fails to cover usage guidance, behavioral traits, or expected outcomes, which are essential for a mutation tool with no other documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning to parameters beyond what the schema provides (title, spreadsheet). It is acceptable but does not enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('creates') and resource ('new sheet tab'), clearly stating the tool's function. It distinguishes from siblings like rename_sheet or add_rows by specifying 'new sheet tab', making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., when to create a sheet vs. how to select one). No context or prerequisites are mentioned, leaving the agent without decision criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_rowsDelete RowsA

Permanently deletes a contiguous block of rows from a sheet tab, shifting the rows below upward. Deletes count rows (default 1) starting at the 1-based start_row. Destructive — cannot be undone via the API.

ParametersJSON Schema

Name	Required	Description
`count`	No	Number of consecutive rows to delete, starting at start_row (default 1)
`start_row`	Yes	1-based index of the first row to delete
`sheet_name`	Yes	Target sheet tab name
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behavioral traits: it explicitly states the operation is destructive and cannot be undone via the API, and describes the shifting effect. This provides comprehensive transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no fluff. It front-loads the main action and effect, then adds specifics and a critical warning. Every sentence is necessary and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, behavior, and destructive nature. However, it omits information about the return value (no output schema exists). For a tool with four parameters, the description is largely complete but lacks this detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description reinforces the count default and 1-based start_row but does not add significant meaning beyond what the schema's property descriptions already provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies that the tool permanently deletes a contiguous block of rows from a sheet tab, shifting rows upward. It uses specific verbs and resources ('deletes rows') and distinguishes from siblings by focusing on row deletion, unlike add_rows or update_row.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context (permanent deletion, shifting rows) but does not explicitly state when not to use this tool or suggest alternatives. It implies usage for removing rows, meeting the criteria for 'clear context, no exclusions'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_rowsFind RowsA

Read-only

Searches a sheet tab for rows whose cell value matches query and returns each match with its 1-based sheet row index (feed straight into update_row / delete_rows). Restrict to one column by 1-based column index OR by column_header name (resolved via header_row); omit both to search every column. Matches the raw unformatted value (numbers/dates by their underlying value, not displayed text). The header_row is treated as headers and excluded from matches.

ParametersJSON Schema

Name	Required	Description	Default
`match`	No	'exact' = whole cell equals query; 'contains' = cell contains query as substring	exact
`query`	Yes	Value to search for
`column`	No	1-based column index to restrict the search to (e.g. 3 = C). Mutually exclusive with column_header
`header_row`	No	1-based row holding headers; used to resolve column_header and excluded from matches (default 1)
`sheet_name`	Yes	Target sheet tab name
`max_results`	No	Maximum number of matching rows to return (default 50)
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID
`column_header`	No	Header name to restrict the search to, matched in header_row. Mutually exclusive with column
`case_sensitive`	No	Match case-sensitively (default false)

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description reveals key behaviors: raw value matching (numbers/dates by underlying value), and header row exclusion. These go beyond the readOnlyHint annotation, providing crucial context without contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, using short sentences and front-loading the core purpose and key constraints. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers parameter interactions, matching behavior, and output format (row index). While it explains return value, it could note that the tool returns all row data? But given the context, it is sufficient and complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the description adds meaning by explaining the mutual exclusivity of column/column_header, the meaning of match modes, and default behavior. It enhances understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Searches a sheet tab for rows whose cell value matches query and returns each match with its 1-based sheet row index'. It distinguishes from sibling tools like get_sheet_data (returns all data) and update_row/delete_rows (uses the index).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on restricting search by column index or header name, and notes that results can feed into update_row/delete_rows. It implies when to use this tool for targeted searches, but could explicitly mention it as an alternative to get_sheet_data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sheet_dataGet Sheet DataB

Read-only

Reads cell values from a range in A1 notation (e.g. 'Sheet1!A1:D10' or 'Sheet1' for the entire tab).

ParametersJSON Schema

Name	Required	Description	Default
`range`	Yes	A1 notation range, e.g. 'Sheet1!A1:D10' or 'Sheet1' for the entire tab
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds the A1 notation detail but does not disclose other behavioral traits like error handling, read limits, or data format. Minimal value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff, front-loaded purpose. However, it could be slightly more structured (e.g., mention that the output is a 2D array) without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description does not explain the return format (e.g., array of arrays, row-major). For a read tool that returns complex data, this is a significant gap. The description is adequate only if the agent already knows the output format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for both parameters. The description mostly repeats the schema's range description (e.g., 'A1 notation range...') and adds no new semantic information. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'reads' and the resource 'cell values' with specific A1 notation. It distinguishes from sibling tools (e.g., update_row, add_columns) by focusing on reading, and from other read tools like find_rows (though not explicitly, the purpose is unambiguous).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like find_rows or get_spreadsheet_info. The description does not specify any prerequisites, limitations, or exclusions, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sheet_schemaGet Sheet SchemaA

Read-only

Returns the structural schema of a sheet tab: column names, dropdown options, checkboxes, data types (date/number/currency), formula-protected fields, and instructional notes. Use this before write operations to understand column constraints.

ParametersJSON Schema

Name	Required	Description
`data_row`	No	1-based row index containing sample data or validation rules (default: header_row + 1)
`header_row`	No	1-based row index where headers are located (default: 1)
`sheet_name`	Yes	Exact name of the sheet tab to analyze
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states it is a read operation (returns schema), consistent with the readOnlyHint annotation. It adds useful behavioral context by listing specific returned elements and stating the purpose (understanding constraints), though it doesn't discuss error handling or auth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first clearly states the action and output, the second provides usage guidance. Every word is purposeful, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the return content. It covers the tool's purpose and constraints. However, it could mention error handling or default behaviors for parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description adds value by explaining what the output contains (column names, dropdown options, etc.), which goes beyond the schema's property descriptions. However, it doesn't link parameters to output specifics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Returns') with a clear resource ('structural schema of a sheet tab') and lists detailed components (column names, dropdowns, data types, etc.), distinguishing it from sibling tools like get_sheet_data (returns data) and get_spreadsheet_info (spreadsheet-level info).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this before write operations to understand column constraints', providing a clear use case. It doesn't mention when not to use it or alternative tools, but the context of siblings implies differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_spreadsheet_infoGet Spreadsheet InfoA

Read-only

Returns metadata about a spreadsheet: title, sheet names, IDs, and dimensions.

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds context about the returned metadata content (title, sheet names, IDs, dimensions) but does not disclose additional behavioral traits such as authentication needs or rate limits. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that conveys all necessary information without redundancy. It is appropriately front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and the presence of annotations and sibling tool names, the description sufficiently covers the return values. However, it lacks details on error handling or authentication scope, which are minor omissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter described as 'Target spreadsheet: a full Google Sheets URL or a bare spreadsheet ID.' The tool description adds no further meaning to the parameter beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns metadata about a spreadsheet, listing specific items like title, sheet names, IDs, and dimensions. This verb+resource structure distinguishes it from sibling tools like get_sheet_data and get_sheet_schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for metadata retrieval but does not explicitly state when to use it versus alternatives like get_sheet_data or get_sheet_schema. No exclusions or usage context are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rename_sheetRename SheetA

Renames a sheet tab. Identify the sheet by sheet_id or old_title.

ParametersJSON Schema

Name	Required	Description
`sheet_id`	No	Numeric sheet ID
`new_title`	Yes	New name for the sheet tab
`old_title`	No	Current sheet title (used if sheet_id is not provided)
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the rename action without mentioning permissions, side effects, or limitations. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loading the core purpose. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters (2 required) and no output schema, the description covers identification but lacks details on error handling, what happens if both identifiers are provided, or any constraints beyond the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by indicating that sheet_id or old_title can be used for identification, but does not explain interaction or precedence. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Renames') and resource ('sheet tab'), and clearly states the identification method (by sheet_id or old_title). It distinguishes from sibling tools like create_sheet or add_columns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining how to identify the sheet, but does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_rowUpdate RowA

Overwrites cells in a single row, left to right, starting at start_column (default column A). Only the cells covered by values are written — cells outside that span are left untouched, so you can update specific columns without rewriting the whole row.

ParametersJSON Schema

Name	Required	Description
`values`	Yes	1D array of values written left-to-right starting at `start_column`
`row_index`	Yes	1-based row number in the sheet
`sheet_name`	Yes	Target sheet tab name
`spreadsheet`	Yes	Target spreadsheet: a full Google Sheets URL (https://docs.google.com/spreadsheets/d/<ID>/edit...) or a bare spreadsheet ID
`start_column`	No	1-based column to start writing at (e.g. 3 = column C). Default 1 (column A)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It discloses the partial overwrite behavior and the left-to-right writing, which is critical for understanding the tool's effect. However, it does not mention error handling or edge cases like out-of-range row indices.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey the core behavior and key parameter details, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (5 params, no output schema, no annotations), the description covers essential behavior for an agent to use the tool correctly. It lacks error handling or result description, but is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage with descriptions for each parameter. The description adds context about start_column's default and the partial overwrite, but does not significantly expand beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it overwrites cells in a single row left-to-right starting at a specified column, distinguishing it from sibling tools like add_rows or delete_rows that add or remove rows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is provided, but the description implies it is for updating specific columns without rewriting the whole row. The sibling tool list offers context but no direct comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.1.0Jul 10, 2026
- First observedadd_columns
- First observedadd_rows
- First observedcreate_sheet
- First observeddelete_rows
- First observedfind_rows
- First observedget_sheet_data
- First observedget_sheet_schema
- First observedget_spreadsheet_info
- First observedrename_sheet
- First observedupdate_row

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct operation: adding rows/columns, creating/renaming sheets, deleting rows, finding rows, reading data/schema/info, and updating rows. Even find_rows and get_sheet_data have clear differences (search vs read range).

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., add_columns, delete_rows, get_sheet_data). The naming is predictable and clear.

Tool Count5/5

With 10 tools, the server covers the core operations for Google Sheets without being overwhelming or too sparse. Each tool serves a clear purpose in spreadsheet management.

Completeness4/5

The tool set covers create, read, update, and delete operations for rows, columns, and sheets. Minor gaps exist (e.g., no delete_columns or delete_sheet), but the main workflows are supported, and agents can work around missing operations.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gcal AOAuth
com.mintmcp
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
Calendar Management App Automation
28
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
Google_docs B
io.github.pipeworx-io
Google Docs MCP Pack — read, create, and edit Google Docs via OAuth.
Workplace & Productivity Content Management Systems App Automation
372

Related MCP Servers

Google Sheets API MCP Server
Workplace & Productivity App Automation
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An MCP server that enables interaction with Google Sheets through natural language, allowing users to create, read, update, and manage spreadsheet data via the Google Sheets API v4.
Updated a year ago (2025-07-12 23:28 UTC)
-
google-sheets-mcp
Workplace & Productivity Cloud Platforms
domdomegg
A
license
Not graded
quality
A
maintenance
MCP server for Google Sheets - read, write, and query spreadsheet data.
Updated a month ago (2026-08-11 21:44 UTC)
178
2
MIT
mcp-gsheet
Workplace & Productivity Databases
shionhonda
A
license
A
quality
D
maintenance
MCP server for interacting with Google Sheets, providing tools to list sheets, read data from cell ranges, and write data to cell ranges.
Updated a year ago (2025-04-12 16:25 UTC)
3
3
MIT
google-sheets-mcp
Workplace & Productivity Cloud Storage
pabgof
A
license
Not graded
quality
C
maintenance
MCP server to read, write, create, and format Google Sheets via OAuth2 authentication, providing tools for spreadsheet management.
Updated 2 months ago (2026-06-30 10:32 UTC)
606
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/toantran201/mcp-google-sheets'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCP Google Sheets

Features

Available Tools

Install

Prerequisites

OAuth Setup (recommended — one-time, per team)

1. Create a Google Cloud Project

2. Enable the Google Sheets API

3. Configure the OAuth Consent Screen

4. Create an OAuth Client ID

First run

Security notes

Service Account Setup (legacy alternative)

1. Create a Service Account

2. Generate a Private Key

3. Share Your Spreadsheet

Local development

Publishing a new version

Restricting Tools

Project Structure

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API