Google Apps Script MCP

Google Apps Script MCP

English | Русский

A1 Google Apps Script MCP lets an AI app write and operate Google Apps Script in plain language. Create a script project, read and edit its code, snapshot versions, manage deployments, run functions and read the execution history.

It uses the Google Apps Script API with your Google account. It distinguishes the editable HEAD code from immutable versions and makes the limits of the Apps Script API explicit instead of implying that every scripting task is possible.

• 19 tools. Create standalone and bound projects, read and update code files, snapshot immutable versions, manage deployments, run functions, and inspect execution history and metrics.
• Connects from the conversation. Say "connect Google Apps Script": the server walks you through the OAuth client, catches Google's redirect on 127.0.0.1 with PKCE and keeps the tokens itself — no config files, no restart.
• Versions are immutable. A version snapshots HEAD and can never be edited or deleted; deployments point at versions, so you ship and roll back without changing a URL.
• The manifest always survives. Merge mode keeps the appsscript manifest and every file you did not mention; replace mode refuses a file set without the manifest before any network traffic.
• Keep your scriptId. The API cannot list projects and cannot delete them — the scriptId returned by create_project is the only handle.
• Minimal Google scopes. Each operation names its own scope (script.projects, script.deployments, script.processes, script.metrics); request only what your tasks need.

Start with a read-only question:

Show me the files in my report script and which functions failed this week.

Connect the server · Explore use cases · Open technical documentation

See it work in a minute

You: Show the code and the recent runs of my report script.

Assistant: Shows every file with its source and the execution history — which functions ran, when, and which failed. Nothing changes.

You: Add a formatDate helper to the Utils file and keep everything else as is.

Assistant: Shows the proposed source and confirms that merge mode leaves the other files untouched, then asks for confirmation before writing.

You: Confirm.

Assistant: Writes the file to HEAD. It does not create a version, redeploy or run anything unless you ask separately.

Contents

• Quick start
• What you can ask it to do
• How a project changes
• What can change
• Getting access
• Configuration
• Data, limits and background work
• Technical documentation
• Support

Quick start

You need Node.js 20+ and a Google account. Credentials are not required at install time — the server connects from the conversation.

1. Add the server to your AI app.
2. Say "connect Google Apps Script": the assistant walks you through creating the OAuth client and approving access without editing config files.
3. Ask the read-only question above.

In the app: open Settings → MCP servers, select Add server, choose STDIO, enter the command npx -y mcp-google-apps-script@latest and environment variables GOOGLE_APPS_SCRIPT_CLIENT_ID, GOOGLE_APPS_SCRIPT_CLIENT_SECRET, GOOGLE_APPS_SCRIPT_REFRESH_TOKEN, then select Save and Restart.

From the command line:

codex mcp add google-apps-script \
  -- npx -y mcp-google-apps-script@latest

codex mcp list

Codex MCP documentation

claude mcp add \
  --transport stdio --scope user google-apps-script \
  -- npx -y mcp-google-apps-script@latest

claude mcp list

Claude Code MCP documentation

The current official path is Settings → Extensions. For a custom desktop extension, open Advanced settings → Extension Developer → Install Extension…, select a .mcpb file and follow the prompts.

This repository currently publishes an npm stdio package and does not contain a .mcpb bundle. For Claude Desktop builds that still support local configuration, use the following JSON stdio configuration as a fallback:

{
  "mcpServers": {
    "google-apps-script": {
      "command": "npx",
      "args": ["-y", "mcp-google-apps-script@latest"]
    }
  }
}

In those builds, save it to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows.

Claude Desktop MCP documentation

Add this to ~/.cursor/mcp.json on macOS/Linux or %USERPROFILE%\.cursor\mcp.json on Windows:

{
  "mcpServers": {
    "google-apps-script": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-google-apps-script@latest"]
    }
  }
}

Cursor MCP documentation

Run MCP: Open User Configuration and add:

{
  "servers": {
    "google-apps-script": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-google-apps-script@latest"]
    }
  }
}

Check it with MCP: List Servers.

VS Code MCP documentation

What you can ask it to do

Inspect a project and its runs

• Show this script's files and explain what each function does.
• Which functions failed this week? Show the execution history for sendDigest.
• How many users, executions and failures did this script have over the last 7 days?

Write and evolve code

• Create a standalone project, or a script bound to a Doc, Sheet, Slides or Form.
• Add a helper function to one file without touching the others.
• Snapshot the current code as a version with a description before we refactor.

Ship, run and roll back

• Deploy version 4 and show its entry points — web app URL or API-executable config.
• Run sendDigest and show the result; if the script throws, show the stack trace.
• Repoint the deployment back to version 3 without changing its URL.

How a project changes

1. create_project creates a project — standalone, or bound to a Doc, Sheet, Slides or Form. Keep the returned scriptId: the API cannot list projects.
2. Code lives at HEAD as files addressed by name without extension. update_project_content merges by default — it upserts the files you name and keeps the rest — and only replaces the entire set when asked; the appsscript manifest can never be deleted.
3. create_version snapshots HEAD as an immutable version — no edit, no delete, numbers only grow.
4. A deployment exposes a version as a web app or API executable. Updating a deployment repoints it at another version without changing its URL; the automatic @HEAD deployment cannot be deleted.

The API cannot delete a project either — that means deleting its Drive file, which this server does not cover. run_function requires an API-executable deployment, an OAuth client from the same Cloud project as the script and the script's own scopes on the token; Apps Script stops any execution after 6 minutes. The execution history shows status and timing but no error messages — those live in Cloud Logging or come from re-running the function.

What can change

The AI client controls confirmation prompts. The server marks reads, writes and destructive tools so the client can distinguish an inspection from a live change.

Getting access

Google Apps Script requires OAuth 2.0; an API key is not enough. There are two ways in, and the first one needs no configuration files.

Connect from the chat (recommended)

Say "connect Google Apps Script" and the assistant runs the flow with you:

1. setup_instructions prints the checklist: create or select a Google Cloud project, enable Apps Script API, configure the consent screen and create a Desktop app OAuth client.
2. Download that client's JSON ("Download JSON") and give the assistant its path — set_client stores it owner-only. The secret never goes through the conversation.
3. start_login returns a Google consent link. Open it on this machine and approve; the code comes back to a one-shot listener on 127.0.0.1 (PKCE), never through the chat.
4. finish_login exchanges the code and saves the tokens to ~/.config/mcp-google-apps-script/credentials.json (mode 0600) and verifies them with a real Apps Script API call — so an API that is still switched off is caught right there.

The tokens are re-read on every call, so the connection works immediately — no restart of the AI app. auth_status shows what is connected, logout revokes and deletes it.

Environment variables (CI, unattended installs)

1. Create or select a Google Cloud project and enable Google Apps Script API.

2. Turn on the per-account toggle at script.google.com/home/usersettings — without it every call fails with 403.

3. Configure the OAuth consent screen and create a Desktop app OAuth client.

4. Authorize the Google account that owns the scripts. The OAuth 2.0 Playground can obtain the refresh token when Use your own OAuth credentials is enabled.

5. Request the scopes for the tools you plan to use:

   https://www.googleapis.com/auth/script.projects
   https://www.googleapis.com/auth/script.deployments
   https://www.googleapis.com/auth/script.processes
   https://www.googleapis.com/auth/script.metrics
   

   For inspection-only use, replace the first two with the read-only variants script.projects.readonly and script.deployments.readonly; list_processes and get_project_metrics still need script.processes and script.metrics, which have no narrower form. run_function needs none of these scopes — instead the token must carry every scope the target script itself uses, and the OAuth client must belong to the same Cloud project as the script.

Testing-mode OAuth refresh tokens can expire after seven days. Publish the OAuth app, or use an Internal app in a Workspace domain, when you need long-lived access. Treat the client secret and refresh token as passwords.

The setup_instructions tool returns this same checklist and works even before credentials are configured.

Configuration

Every variable is optional — with none of them the server connects from the chat.

* Provide either the OAuth trio or an access token.

Data, limits and background work

• Requests go to Google Apps Script. The local server refreshes Google OAuth tokens and calls the Apps Script API. Its anonymous telemetry contains an installation ID, package version, AI client and platform versions, and tool names — never OAuth tokens, script sources, tool arguments or prompts. Set ASKADS_TELEMETRY=0 to opt out.
• Writes are never replayed blindly. On 429, the server uses backoff; reads also retry after network and 5xx errors, while writes are not replayed after an uncertain failure — a duplicated create_version piles up immutable versions, and a duplicated run_function executes side effects twice. After an ambiguous failure, check list_versions or the execution history instead of re-sending.
• There is no background polling. The server runs only when called, and a function executes only when you ask for it. Scripts keep their own Apps Script triggers on Google's side; if your AI app supports scheduled tasks, it can also check the execution history periodically.

Technical documentation

• MCP capability catalog — task-oriented pages for every tool.
• All tools and inputs
• Development documentation
• Publishing documentation
• Google Apps Script API reference

Support

Found a bug or need a scenario? Create an issue or write in Telegram.