{
"answer": "The Google Apps Script MCP Server lets you fully manage Apps Script projects, deployments, versions, and executions from any MCP client (Claude Desktop, VS Code, Postman, etc.) via the REST API.\n\nProject Management — Create, retrieve metadata, get/update source content, and discover projects by name via Drive.\n\nVersion Control — Create, get, and list version snapshots of a script project.\n\nDeployment Management — Create, get, list, update (repoint to a version or HEAD), and delete deployments.\n\nScript Execution — Run a function remotely with optional parameters and dev/HEAD mode.\n\nMonitoring & Metrics — List execution processes with rich filtering, view recent executions (with an optional failures-only filter), and retrieve deployment metrics/analytics.\n\nWeb App Publishing — Publish a web app in one step (update content → create version → repoint deployment, keeping the URL stable) and retrieve /exec URLs with access configuration.\n\nDev/Diagnostic Tools (hidden unless DEV_TOOLS=1) — Check auth status (token validity/scopes), view server info (version, uptime, loaded tools), and hot-reload tool files without restarting.\n\nAuthentication — Robust OAuth 2.0 with refresh token storage, automatic single-flight token refresh, retry/timeout handling, and least-privilege scope presets (read-only vs. full deploy/publish)."
}
Provides tools for managing Google Apps Script projects, deployments, versions, content, processes, metrics, and executing script functions remotely through the Google Apps Script API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@google-appscript-mcp-server create a new deployment for my Apps Script project"
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.
Original Author: mohalmah
License: MIT License
Upstream Repository: mohalmah/google-appscript-mcp-server
🍴 Fork notice
This is a fork of mohalmah/google-appscript-mcp-server, maintained by andyconley. Full credit for the original server goes to mohalmah.
This fork adds the following fixes on top of upstream:
OAuth on all write tools —
deploymentsupdate/delete,get-metrics,versions-get, andlist-script-processeswere authenticating against a non-existentGOOGLE_APP_SCRIPT_API_API_KEYenv var (sendingBearer undefined) and returned 401 out of the box; they now use the same OAuth path as the working read tools.stdio-safe logging — diagnostic logs were written to stdout, which is the JSON-RPC channel in stdio mode; they now go to stderr so they can't corrupt the protocol.
Unified failure contract — tool failures are surfaced via MCP's
isErrorflag instead of being returned as success payloads.Single-flight token refresh — concurrent tool calls near token expiry no longer each fire their own refresh (which could race and invalidate each other).
An MCP (Model Context Protocol) server for the Google Apps Script API. Manage script projects, deployments, versions, and executions from any MCP client — Claude Desktop, VS Code with Cline, or Postman.
Related MCP server: Google Workspace MCP Server
What you get:
OAuth 2.0 — refresh token stored in an OS-specific dir at file mode 600, refreshed automatically
Full Apps Script REST API coverage — plus the tools this fork adds (below)
Works with any MCP client — Claude Desktop, VS Code, Postman
Structured logging — to stderr, with adjustable levels
This fork keeps the full upstream toolset and adds the following. See the fork notice above for the reliability fixes; the capabilities below are new.
New tools
publish_web_app — one call to publish a web app: optionally update content, create a version, and repoint an existing deployment to it (the deployment URL stays stable). Wraps the manual update_script_content → versions.create → deployments.update flow so it can't be left half-done.
get_web_app_url — return the /exec URL(s) and access config (access, executeAs, version) for a project's deployments.
list_script_projects — discover Apps Script projects via the Drive API (the Apps Script API has no "list my projects"). Returns each project's scriptId and name. Requires the drive.metadata.readonly scope — re-run OAuth setup to re-consent before it works (see Re-consenting for new scopes).
recent_executions — list a project's recent runs (function, status, type, start time, duration) with an onlyFailures filter. Uses execution metadata — no extra scope, and does not include console.log output (that lives in Cloud Logging).
Fixes to existing tools
script_run now actually runs a function. It previously sent an empty POST body (no function), so it could never execute anything. It now accepts functionName, parameters, and devMode.
deployments.update — versionNumber is now optional; omit it to track HEAD (latest saved content).
Dev / diagnostic tools (hidden unless DEV_TOOLS=1)
auth_status — token validity, expiry, and granted-vs-requested scopes (never exposes the token). The fastest way to tell an auth problem (missing scope) from a code problem (endpoint bug).
server_info — version, pid, uptime, transport, log level, loaded tools.
reload_tools — hot-reload tool files into the running server without a restart (see Restarting & reloading).
Operational
bin/restart-dev.sh — restart helper for core changes.
SSE mode now binds to 127.0.0.1 by default (override with SSE_HOST) because the SSE endpoints are unauthenticated.
Deploy an interactive HTML page as a web app — point any MCP client (Claude, Codex, VS Code/Cline, …) at this server and publish a self-contained HTML page to a live /exec URL.
Releases are generated from Conventional Commits on main. The release workflow updates CHANGELOG.md, bumps package.json and package-lock.json, tags the release, and publishes GitHub release notes. This fork does not publish to npm.
Documentation-only releases should still point readers at the changed setup, tool, or operational guidance.
Watch the Google Apps Script MCP Server in action - creating projects, managing deployments, and executing scripts through VS Code AI Agent.
Project Management: Create, retrieve, and update Google Apps Script projects
Deployment Management: Create, list, update, and delete script deployments
Version Control: Create and manage script versions
Content Management: Get and update script content and files
Process Monitoring: List and monitor script execution processes
Metrics Access: Retrieve script execution metrics and analytics
Script Execution: Run Google Apps Script functions remotely
OAuth 2.0: full Google OAuth flow
Token storage: refresh token written to an OS-specific dir at file mode 600 (not the OS keychain)
Automatic refresh: no manual token handling
Credentials via env vars: client ID/secret in .env (gitignored)
Before starting, ensure you have:
Node.js (v18+ required, v20+ recommended) - Download here
npm (included with Node.js)
Google Account with access to Google Cloud Console
Git (for cloning the repository)
git clone https://github.com/andyconley/google-appscript-mcp-server.git
cd google-appscript-mcp-servernpm installFollow the detailed OAuth setup guide below.
npm run setup-oauthnpm startClone the repository:
git clone https://github.com/andyconley/google-appscript-mcp-server.git
cd google-appscript-mcp-serverInstall dependencies:
npm installGo to Google Cloud Console
Click the project dropdown at the top
Click "New Project" or select an existing project
If creating new:
Enter a project name (e.g., "Google Apps Script MCP")
Note your Project ID (you'll need this)
Click "Create"
In the Google Cloud Console, navigate to APIs & Services → Library
Search for and enable the following APIs:
Google Apps Script API (required)
Google Drive API (recommended for file access)
Google Cloud Resource Manager API (for project operations)
For Google Apps Script API:
Search "Google Apps Script API"
Click on the result
Click "Enable"
Wait for the API to be enabled (may take a few minutes)
Go to APIs & Services → OAuth consent screen
Choose External (unless you're in a Google Workspace organization)
Fill in the required information:
App name: "Google Apps Script MCP Server"
User support email: Your email address
App logo: (optional)
App domain: Leave blank for development
Developer contact information: Your email address
Click "Save and Continue"
Configure Scopes (Optional but Recommended):
Click "Add or Remove Scopes"
Add these scopes (this is the full set the server requests — see OAuth Scopes Reference for which tool needs which):
https://www.googleapis.com/auth/script.projects
https://www.googleapis.com/auth/script.projects.readonly
https://www.googleapis.com/auth/script.deployments
https://www.googleapis.com/auth/script.deployments.readonly
https://www.googleapis.com/auth/script.metrics
https://www.googleapis.com/auth/script.processes
https://www.googleapis.com/auth/script.webapp.deploy
https://www.googleapis.com/auth/drive.metadata.readonly
Click "Update"
You can grant a subset for least privilege — e.g. a read-only user needs only the
.readonlyscopes. See the OAuth Scopes Reference table below. Runauth_status(withDEV_TOOLS=1) to see granted vs. missing scopes at any time.
Add Test Users (for External apps):
Click "Add Users"
Add your Gmail address as a test user
Click "Save and Continue"
Go to APIs & Services → Credentials
Click "+ CREATE CREDENTIALS" → "OAuth 2.0 Client IDs"
For Application Type, select "Web application"
Configure the client:
Name: "Google Apps Script MCP Client"
Authorized JavaScript origins: (leave empty for now)
Authorized redirect URIs: Add exactly this URL:
http://localhost:3001/oauth/callbackClick "Create"
IMPORTANT: Copy your Client ID and Client Secret immediately
Client ID looks like: 1234567890-abcdefghijklmnop.apps.googleusercontent.com
Client Secret looks like: GOCSPX-abcdefghijklmnopqrstuvwxyz
Create a .env file in your project root:
# On Windows
type nul > .env
# On macOS/Linux
touch .envEdit the .env file and add your credentials:
# Google Apps Script API OAuth Configuration
GOOGLE_APP_SCRIPT_API_CLIENT_ID=your_client_id_here
GOOGLE_APP_SCRIPT_API_CLIENT_SECRET=your_client_secret_here
# Optional: Logging level
LOG_LEVEL=infoReplace the placeholders with your actual values:
Replace your_client_id_here with your Client ID
Replace your_client_secret_here with your Client Secret
Execute the OAuth setup script:
npm run setup-oauthWhat this does:
Starts a temporary local server on http://localhost:3001
Opens your default browser to Google's authorization page
Asks you to grant permissions to the application
Captures the authorization code via the callback URL
Exchanges the code for access and refresh tokens
Stores the refresh token securely in your OS credential store
Tests the token by making a test API call
When your browser opens:
Select your Google account (must be the test user you added)
Review the permissions being requested:
See and manage your Google Apps Script projects
See your script executions and metrics
Access your script deployments
Click "Continue" or "Allow"
You should see: "OAuth setup completed successfully!"
The setup process stores tokens securely:
Windows: Windows Credential Manager
macOS: Keychain Access
Linux: Secret Service API (GNOME Keyring/KDE Wallet)
npm startYou should see output like:
Google Apps Script MCP Server running on stdio
OAuth tokens loaded successfully
Server ready to handle MCP requests# List all available tools
npm run list-tools
# Test OAuth connection
npm run test-oauth
# Enable debug logging
npm run debugThis MCP server provides 16 comprehensive tools for Google Apps Script management:
script-projects-createPurpose: Create a new Google Apps Script project Parameters:
title (required): The title of the new script project
parentId (optional): The ID of the parent project
Example Usage: Create a new script for automation tasks
// Creates: "My Automation Script" project
{
"title": "My Automation Script",
"parentId": "1234567890"
}script-projects-getPurpose: Get metadata of a Google Apps Script project Parameters:
scriptId (required): The ID of the script project to retrieve
fields (optional): Specific fields to include in response
alt (optional): Data format for response (default: 'json')
Example Usage: Retrieve project information
// Gets project details for script ID
{
"scriptId": "1ABC123def456GHI789jkl"
}script-projects-get-contentPurpose: Get the content of a Google Apps Script project Parameters:
scriptId (required): The ID of the script project
versionNumber (optional): Specific version number to retrieve
What it returns: Complete source code and files in the project Example Usage: Download script source code for backup or analysis
script-projects-update-contentPurpose: Update the content of a Google Apps Script project Parameters:
scriptId (required): The ID of the script project to update
files (required): Array of file objects with name, type, and source
Example Usage: Deploy code changes to your script project
script-projects-versions-createPurpose: Create a new version of a Google Apps Script project Parameters:
scriptId (required): The ID of the script project
description (required): Description for the new version
Example Usage: Create versioned snapshots for deployment
{
"scriptId": "1ABC123def456GHI789jkl",
"description": "Added email notification feature"
}script-projects-versions-getPurpose: Get details of a specific script version Parameters:
scriptId (required): The ID of the script project
versionNumber (required): The version number to retrieve
script-projects-versions-listPurpose: List all versions of a script project Parameters:
scriptId (required): The ID of the script project
pageSize (optional): Number of versions per page
pageToken (optional): Token for pagination
script-projects-deployments-createPurpose: Create a deployment of a Google Apps Script project Parameters:
scriptId (required): The ID of the script to deploy
versionNumber (required): Version number to deploy
manifestFileName (required): Name of the manifest file
description (required): Description for the deployment
Example Usage: Deploy your script as a web app or API executable
{
"scriptId": "1ABC123def456GHI789jkl",
"versionNumber": 3,
"manifestFileName": "appsscript.json",
"description": "Production deployment v1.2"
}script-projects-deployments-getPurpose: Get details of a specific deployment Parameters:
scriptId (required): The ID of the script project
deploymentId (required): The ID of the deployment
script-projects-deployments-listPurpose: List all deployments of a script project Parameters:
scriptId (required): The ID of the script project
pageSize (optional): Number of deployments per page
script-projects-deployments-updatePurpose: Update an existing deployment Parameters:
scriptId (required): The ID of the script project
deploymentId (required): The ID of the deployment to update
deploymentConfig (required): New deployment configuration
script-projects-deployments-deletePurpose: Delete a deployment Parameters:
scriptId (required): The ID of the script project
deploymentId (required): The ID of the deployment to delete
script-scripts-runPurpose: Execute a Google Apps Script function Parameters:
scriptId (required): The ID of the script to run
Additional parameters specific to the function being executed
Example Usage: Trigger script execution remotely Note: The script must be deployed and you must have execution permissions
script-processes-listPurpose: List execution processes for a script project Parameters:
scriptId (required): The ID of the script project
pageSize (optional): Number of processes per page
pageToken (optional): Token for pagination
statuses (optional): Filter by process statuses
types (optional): Filter by process types
functionName (optional): Filter by function name
startTime (optional): Filter by start time
endTime (optional): Filter by end time
What it shows: Running, completed, and failed script executions
script-processes-list-script-processesPurpose: Alternative method to list script processes with additional filtering
Parameters: Similar to script-processes-list with enhanced filtering options
script-projects-get-metricsPurpose: Get execution metrics and analytics for a script project Parameters:
scriptId (required): The ID of the script project
deploymentId (required): The ID of the deployment
metricsGranularity (required): Granularity of metrics data
fields (required): Specific metric fields to retrieve
What it provides:
Execution counts
Error rates
Performance metrics
Usage analytics
These tools are added by this fork (see What This Fork Adds).
publish_web_appPurpose: Publish a web app in one call (optionally update content → create version → repoint an existing deployment). The deployment URL stays stable. Parameters:
scriptId (required): The script project ID
deploymentId (required): The existing deployment to repoint
description (optional): Version/deployment description
files (optional): Project files to write first (Apps Script content format); if omitted, the current saved content is published
get_web_app_urlPurpose: Get the web app /exec URL(s) and access config for a project.
Parameters:
scriptId (required): The script project ID
deploymentId (optional): A specific deployment; if omitted, all deployments are scanned
list_script_projectsPurpose: Discover the user's Apps Script projects via Drive (returns scriptId + name). Use when you don't already have a scriptId.
Parameters: nameContains (optional), pageSize (optional), pageToken (optional)
Note: Requires the drive.metadata.readonly scope — see Re-consenting for new scopes.
recent_executionsPurpose: List a project's recent executions (runs) — function, status, type, start time, duration — with a failures count. The "what ran and did it fail" view. Uses execution metadata only; does not return console.log output.
Parameters:
scriptId (required): The script project ID
onlyFailures (optional): Only return failed / timed-out / canceled runs
functionName (optional): Filter to a specific function
pageSize (optional), pageToken (optional)
Hidden unless DEV_TOOLS=1 (see Environment Variables).
Tool | Purpose |
| Token validity, expiry, and granted-vs-requested scopes (token never exposed). |
| Version, pid, uptime, transport, log level, loaded tools. |
| Hot-reload tool files into the running server without a restart. |
Category | Tools | Purpose |
Project Management | create, get, get-content, update-content | Manage script projects and source code |
Version Control | versions-create, versions-get, versions-list | Handle script versioning |
Deployment | deployments-create, deployments-get, deployments-list, deployments-update, deployments-delete | Manage script deployments |
Execution | scripts-run | Execute script functions |
Monitoring | processes-list, get-metrics | Monitor execution and performance |
Fork: Web App | publish_web_app, get_web_app_url | Publish and inspect web app deployments |
Fork: Discovery | list_script_projects | Find projects by name (Drive) |
Fork: Monitoring | recent_executions | Recent runs + failures (execution metadata) |
Fork: Dev (DEV_TOOLS=1) | auth_status, server_info, reload_tools | Diagnostics and hot-reload |
Which scope each tool needs. Scopes are per Google's Apps Script API reference (each method's authoritative scope list lives in Google's docs); a read operation also works with the corresponding broader write scope, so the read-only scopes matter only if you're granting least privilege. Run auth_status (DEV_TOOLS=1) to see granted vs. missing at any time.
Tool | API operation | Required scope |
| projects.create |
|
| projects.updateContent |
|
| projects.versions.create |
|
| projects.get |
|
| projects.getContent |
|
| projects.versions.get |
|
| projects.versions.list |
|
| deployments.create |
|
| deployments.update |
|
| deployments.delete |
|
| deployments.get |
|
| deployments.list |
|
| projects.getMetrics |
|
| processes.list |
|
| processes.listScriptProcesses |
|
| scripts.run | The scopes the target script itself uses (not a fixed API scope). The script must also share the calling OAuth client's Cloud project. |
| updateContent + versions.create + deployments.update |
|
| deployments.get/list |
|
| Drive files.list |
|
| processes.listScriptProcesses |
|
| local only | none |
Least-privilege presets:
Read-only: script.projects.readonly, script.deployments.readonly, script.processes, script.metrics, drive.metadata.readonly
Full (deploy/publish): add script.projects, script.deployments, script.webapp.deploy
Development Workflow:
Use script-projects-create to create new projects
Use script-projects-update-content to upload code
Use script-projects-versions-create to create stable versions
Use script-projects-deployments-create to deploy for production
Monitoring and Debugging:
Use script-processes-list to see execution history
Use script-projects-get-metrics to analyze performance
Use script-projects-get-content to backup source code
Production Management:
Use script-projects-deployments-list to see all deployments
Use script-projects-deployments-update to update production configs
Use script-scripts-run to trigger automated workflows
The MCP Server (mcpServer.js) exposes your automated API tools to MCP-compatible clients, such as Claude Desktop or the Postman Desktop Application. We recommend that you test the server with Postman first and then move on to using it with an LLM.
Step 1: Download the latest Postman Desktop Application from https://www.postman.com/downloads/.
Step 2: Read the documentation article here and see how to create an MCP request inside the Postman app.
Step 3: Set the type of the MCP request to STDIO and set the command to node <absolute/path/to/mcpServer.js>.
For Windows users, you can get the full path to node by running:
Get-Command node | Select-Object -ExpandProperty SourceFor macOS/Linux users, you can get the full path to node by running:
which nodeTo check the node version on any platform, run:
node --versionFor Windows users, to get the absolute path to mcpServer.js, run:
Get-Location | Select-Object -ExpandProperty PathThen append \mcpServer.js to the path.
For macOS/Linux users, to get the absolute path to mcpServer.js, run:
realpath mcpServer.jsUse the node command followed by the full path to mcpServer.js as the command for your new Postman MCP Request. Then click the Connect button. You should see a list of tools that you selected before generating the server. You can test that each tool works here before connecting the MCP server to an LLM.
You can connect your MCP server to various MCP clients. Below are detailed instructions for both Claude Desktop and VS Code.
Before configuring any MCP client, you'll need the absolute paths to Node.js and your mcpServer.js file.
Get Node.js path:
Get-Command node | Select-Object -ExpandProperty SourceExample output: C:\nvm4w\nodejs\node.exe
Alternative method if first doesn't work:
where.exe nodeGet current directory path:
Get-Location | Select-Object -ExpandProperty PathExample output: C:\Users\mohal\Downloads\google-appscriot-mcp-server
Complete mcpServer.js path:
Join-Path (Get-Location) "mcpServer.js"Example output: C:\Users\mohal\Downloads\google-appscriot-mcp-server\mcpServer.js
Quick copy-paste command to get both paths:
Write-Host "Node.js path: $((Get-Command node).Source)"
Write-Host "mcpServer.js path: $(Join-Path (Get-Location) 'mcpServer.js')"Get Node.js path:
which nodeExample output: /usr/local/bin/node or /opt/homebrew/bin/node
Get mcpServer.js path:
realpath mcpServer.jsExample output: /Users/username/google-appscript-mcp-server/mcpServer.js
Alternative method:
echo "$(pwd)/mcpServer.js"Quick copy-paste command to get both paths:
echo "Node.js path: $(which node)"
echo "mcpServer.js path: $(realpath mcpServer.js)"Get Node.js path:
which nodeExample output: /usr/bin/node or /usr/local/bin/node
Get mcpServer.js path:
realpath mcpServer.jsExample output: /home/username/google-appscript-mcp-server/mcpServer.js
Quick copy-paste command to get both paths:
echo "Node.js path: $(which node)"
echo "mcpServer.js path: $(realpath mcpServer.js)"On any platform, verify your Node.js version:
node --versionEnsure it shows v18.0.0 or higher.
Step 1: Note the full paths from the previous section.
Step 2: Open Claude Desktop and navigate to:
Settings → Developers → Edit Config
Step 3: Add your MCP server configuration:
{
"mcpServers": {
"google-apps-script": {
"command": "<absolute_path_to_node_executable>",
"args": ["<absolute_path_to_mcpServer.js>"],
"env": {
"GOOGLE_APP_SCRIPT_API_CLIENT_ID": "your_client_id_here",
"GOOGLE_APP_SCRIPT_API_CLIENT_SECRET": "your_client_secret_here"
}
}
}
}{
"mcpServers": {
"google-apps-script": {
"command": "C:\\nvm4w\\nodejs\\node.exe",
"args": ["C:\\Users\\mohal\\Downloads\\google-appscriot-mcp-server\\mcpServer.js"],
"env": {
"GOOGLE_APP_SCRIPT_API_CLIENT_ID": "1234567890-abcdefghijk.apps.googleusercontent.com",
"GOOGLE_APP_SCRIPT_API_CLIENT_SECRET": "GOCSPX-abcdefghijklmnopqrstuvwxyz"
}
}
}
}{
"mcpServers": {
"google-apps-script": {
"command": "/usr/local/bin/node",
"args": ["/Users/username/google-appscript-mcp-server/mcpServer.js"],
"env": {
"GOOGLE_APP_SCRIPT_API_CLIENT_ID": "1234567890-abcdefghijk.apps.googleusercontent.com",
"GOOGLE_APP_SCRIPT_API_CLIENT_SECRET": "GOCSPX-abcdefghijklmnopqrstuvwxyz"
}
}
}
}Step 4: Replace the OAuth credentials with your actual values from the .env file.
Step 5: Save the configuration and restart Claude Desktop.
Step 6: Verify the connection by checking that the MCP server shows a green circle indicator next to it in Claude Desktop.
VS Code can use MCP servers through extensions like Cline or other MCP-compatible extensions.
Step 1: Install the Cline extension from the VS Code marketplace.
Step 2: Open VS Code settings (Ctrl+, on Windows/Linux, Cmd+, on macOS).
Step 3: Search for "Cline" or "MCP" in the settings.
Step 4: Add your MCP server configuration:
Add to your VS Code settings.json (accessible via Ctrl+Shift+P → "Preferences: Open Settings (JSON)"):
{
"cline.mcpServers": {
"google-apps-script": {
"command": "C:\\nvm4w\\nodejs\\node.exe",
"args": ["C:\\Users\\mohal\\Downloads\\google-appscriot-mcp-server\\mcpServer.js"],
"env": {
"GOOGLE_APP_SCRIPT_API_CLIENT_ID": "your_client_id_here",
"GOOGLE_APP_SCRIPT_API_CLIENT_SECRET": "your_client_secret_here"
}
}
}
}Create a .vscode/settings.json file in your project root:
{
"cline.mcpServers": {
"google-apps-script": {
"command": "node",
"args": ["./mcpServer.js"],
"env": {
"GOOGLE_APP_SCRIPT_API_CLIENT_ID": "your_client_id_here",
"GOOGLE_APP_SCRIPT_API_CLIENT_SECRET": "your_client_secret_here"
}
}
}
}Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude-desktop/claude_desktop_config.json
Windows: %APPDATA%\Code\User\settings.json
macOS: ~/Library/Application Support/Code/User/settings.json
Linux: ~/.config/Code/User/settings.json
Replace these paths with your actual system paths:
{
"mcpServers": {
"google-apps-script": {
"command": "C:\\nvm4w\\nodejs\\node.exe",
"args": ["C:\\Users\\mohal\\Downloads\\google-appscriot-mcp-server\\mcpServer.js"],
"env": {
"GOOGLE_APP_SCRIPT_API_CLIENT_ID": "your_actual_client_id",
"GOOGLE_APP_SCRIPT_API_CLIENT_SECRET": "your_actual_client_secret"
}
}
}
}{
"mcpServers": {
"google-apps-script": {
"command": "/usr/local/bin/node",
"args": ["/Users/username/google-appscript-mcp-server/mcpServer.js"],
"env": {
"GOOGLE_APP_SCRIPT_API_CLIENT_ID": "your_actual_client_id",
"GOOGLE_APP_SCRIPT_API_CLIENT_SECRET": "your_actual_client_secret"
}
}
}
}{
"mcpServers": {
"google-apps-script": {
"command": "/usr/bin/node",
"args": ["/home/username/google-appscript-mcp-server/mcpServer.js"],
"env": {
"GOOGLE_APP_SCRIPT_API_CLIENT_ID": "your_actual_client_id",
"GOOGLE_APP_SCRIPT_API_CLIENT_SECRET": "your_actual_client_secret"
}
}
}
}🔑 Remember to:
Replace your_actual_client_id and your_actual_client_secret with your OAuth credentials
Update the paths based on your actual system output from the commands above
Use your actual username instead of username in the paths
Ensure you've run npm run setup-oauth before configuring MCP clients
Tests use the built-in Node test runner (node --test) — no extra dependencies.
npm test # hermetic unit + contract tests (no credentials, no network)
npm run test:integration # opt-in live tests against the Google API (see below)
npm run lint # ESLint
npm run format # Prettier (write); `npm run format:check` to verifyWhat the hermetic suite covers:
Schema / contract — every registered tool loads with a valid, unique schema (a tool that fails to import is caught here); dev tools are hidden unless DEV_TOOLS=1.
Request shaping — each tool builds the expected method / URL (with URL-encoded ids) / query / body, and returns the standard { error: true } shape on failure. Auth and fetch are mocked, so these run fully offline.
Client & token manager — URL building, array-query expansion, error parsing, request timeout, retry policy (429 for any method; 5xx/timeout for idempotent GETs only), single-flight refresh, and the token cache.
Opt-in integration tests hit the live Google API and are skipped by default. Authorize first (node oauth-setup.js), then:
RUN_INTEGRATION=1 INTEGRATION_SCRIPT_ID=<a scriptId you can read> npm run test:integrationCI (GitHub Actions, .github/workflows/ci.yml) runs ESLint, a Prettier format check, the hermetic suite, and npm audit --audit-level=high on every push and pull request.
Problem: MCP client can't find Node.js executable Solutions:
Ensure Node.js is properly installed and in your PATH
Use absolute paths to the Node.js executable (recommended)
Verify Node.js version is 18+ using node --version
On Windows, check if multiple Node.js versions are installed
Problem: Your Node.js version is below 18 Solutions:
Recommended: Upgrade to Node.js 18+
Alternative: Install node-fetch as a dependency:
npm install node-fetchThen modify each tool file to import fetch:
import fetch from 'node-fetch';Problem: Authentication failures or token issues Solutions:
Verify your OAuth credentials are correct in the .env file
Ensure environment variables are properly set in the MCP configuration
Re-run the OAuth setup: npm run setup-oauth
Check that you've followed all steps in the Google Cloud Console setup
Verify the callback URL is exactly: http://localhost:3001/oauth/callback
Make sure your Google account is added as a test user
Problem: Google OAuth consent screen configuration issues Solutions:
Ensure your app is configured for "External" users
Add your Gmail address as a test user in OAuth consent screen
Verify all required scopes are added
Make sure the OAuth consent screen is properly published
Problem: Configuration file syntax or path issues Solutions:
Check the configuration file syntax (valid JSON)
Ensure file paths use proper escaping (double backslashes on Windows)
Restart Claude Desktop after configuration changes
Check Claude Desktop logs for error messages
Verify the config file is in the correct location
Problem: Extension not recognizing MCP server Solutions:
Verify the extension is properly installed and enabled
Check that the MCP configuration is in the correct settings location
Reload the VS Code window after configuration changes
Use workspace-specific settings if global settings don't work
Problem: File permission issues Solutions:
Make the mcpServer.js file executable: chmod +x mcpServer.js
Or use the full node command: node /path/to/mcpServer.js
Check file ownership and permissions
Problem: Port 3001 is already in use during OAuth setup Solutions:
Kill any processes using port 3001:
# Find process using port 3001
lsof -i :3001 # macOS/Linux
netstat -ano | findstr :3001 # Windows
# Kill the process
kill -9 <PID> # macOS/Linux
taskkill /PID <PID> /F # WindowsOr temporarily change the port in oauth-setup.js
Problem: OAuth tokens have expired or are invalid Solutions:
Re-run the OAuth setup: npm run setup-oauth
Clear stored tokens and re-authenticate
Check that your OAuth app credentials haven't changed
Verify the OAuth app is still active in Google Cloud Console
Problem: Can't execute scripts or access projects Solutions:
Ensure your Google account has access to the Apps Script projects
Verify the script is shared with your account
Check that the required scopes are granted
For script execution, ensure the script is deployed and executable
npm startIf it starts without errors, your basic setup is correct.
npm run test-oauthThis verifies your OAuth setup is working correctly.
npm run debugThis provides detailed logging to help identify issues.
npm run list-toolsThis lists all available tools and their parameters.
Set the LOG_LEVEL environment variable:
# In .env file
LOG_LEVEL=debug
# Or run with debug
npm run debugThe OAuth setup process provides detailed output. Watch for:
Browser opening successfully
Authorization code capture
Token exchange success
Test API call success
Success Messages:
OAuth tokens loaded successfully
Server ready to handle MCP requests
Tool executed successfully
Warning Messages:
Token refresh required (normal operation)
Retrying API call with refreshed token
Error Messages:
OAuth credentials not found → Check .env file
Failed to refresh token → Re-run OAuth setup
API call failed → Check permissions and quotas
Google Apps Script API Documentation: https://developers.google.com/apps-script/api
MCP Protocol Documentation: https://modelcontextprotocol.io/
OAuth 2.0 Guide: https://developers.google.com/identity/protocols/oauth2
When seeking help, please provide:
Node.js version (node --version)
Operating system and version
Error messages from console/logs
Steps you followed before the error
Contents of your .env file (without secrets)
MCP client configuration (without secrets)
# Required OAuth credentials
GOOGLE_APP_SCRIPT_API_CLIENT_ID=your_client_id
GOOGLE_APP_SCRIPT_API_CLIENT_SECRET=your_client_secret
# Optional configuration
LOG_LEVEL=info # debug, info, warn, error
NODE_ENV=development # development, production
PORT=3001 # OAuth callback port
# Fork additions
DEV_TOOLS=1 # expose dev tools (auth_status, server_info, reload_tools); omit/0 to hide
SSE_HOST=127.0.0.1 # SSE bind host; defaults to loopback (endpoints are unauthenticated)
REQUEST_TIMEOUT_MS=45000 # per-request timeout for Google API calls (default 45s)Reliability: every Google API request goes through a shared client with a per-request timeout (REQUEST_TIMEOUT_MS) and bounded retry — 429 is retried for any method; 5xx/network/timeout are retried only for idempotent GETs (so a retried write can't duplicate a create).
debug: Detailed debugging information
info: General information messages
warn: Warning messages
error: Error messages only
A stdio MCP server can't restart itself — its lifecycle is owned by the MCP client (e.g. Claude Desktop), which does the initialize handshake once. So how you pick up changes depends on what you changed:
Editing a tool file (tools/**): call the reload_tools tool (requires DEV_TOOLS=1). It hot-reloads tool modules into the running server — no restart, session stays live.
Editing core (mcpServer.js, lib/*, scopes): run bin/restart-dev.sh to stop the process, then let your client reconnect (it respawns a fresh process with the updated code). The client's reconnect/relaunch is what actually re-establishes the session.
# core change -> stop the process; client respawns fresh code on next call/reconnect
./bin/restart-dev.shlist_script_projects uses the Drive API and needs the drive.metadata.readonly scope. A token only carries the scopes granted at consent time, so after a scope is added you must re-consent:
Revoke the app's current grant at https://myaccount.google.com/permissions
Re-run OAuth setup: node oauth-setup.js
Run auth_status (with DEV_TOOLS=1) at any time to see exactly which requested scopes are granted vs. missing.
# Install PM2
npm install -g pm2
# Start with PM2
pm2 start mcpServer.js --name "gas-mcp-server"
# Monitor
pm2 status
pm2 logs gas-mcp-server
# Auto-restart on system boot
pm2 startup
pm2 saveBuild Docker image:
docker build -t google-apps-script-mcp .Run with Docker:
docker run -i --rm --env-file=.env google-apps-script-mcpDocker Compose setup:
version: '3.8'
services:
gas-mcp:
build: .
env_file:
- .env
stdin_open: true
tty: true{
"mcpServers": {
"google-apps-script": {
"command": "docker",
"args": ["run", "-i", "--rm", "--env-file=.env", "google-apps-script-mcp"]
}
}
}Create a new tool file in tools/google-app-script-api/apps-script-api/:
import { getAuthHeaders } from '../../../lib/oauth-helper.js';
const executeFunction = async ({ param1, param2 }) => {
const baseUrl = 'https://script.googleapis.com';
try {
const headers = await getAuthHeaders();
const response = await fetch(`${baseUrl}/v1/your-endpoint`, {
method: 'POST',
headers,
body: JSON.stringify({ param1, param2 })
});
return await response.json();
} catch (error) {
throw new Error(`API call failed: ${error.message}`);
}
};
export { executeFunction };Add to paths.js:
export const toolPaths = [
// ...existing paths...
'google-app-script-api/apps-script-api/your-new-tool.js'
];Update tool descriptions in your MCP server tool definitions.
import { getAuthHeaders } from '../../../lib/oauth-helper.js';
/**
* Tool description and JSDoc comments
*/
const executeFunction = async (args) => {
const baseUrl = 'https://script.googleapis.com';
try {
// 1. Validate parameters
if (!args.requiredParam) {
throw new Error('requiredParam is required');
}
// 2. Get authentication headers
const headers = await getAuthHeaders();
// 3. Make API call
const response = await fetch(`${baseUrl}/v1/endpoint`, {
method: 'GET/POST/PUT/DELETE',
headers,
body: JSON.stringify(args) // for POST/PUT
});
// 4. Handle response
if (!response.ok) {
throw new Error(`API error: ${response.status} ${response.statusText}`);
}
return await response.json();
} catch (error) {
console.error('Tool execution failed:', error);
throw error;
}
};
export { executeFunction };For real-time communication with web interfaces:
npm run start-sseThe server will run on HTTP with SSE support for streaming responses.
NODE_ENV=development
LOG_LEVEL=debug
GOOGLE_APP_SCRIPT_API_CLIENT_ID=dev_client_id
GOOGLE_APP_SCRIPT_API_CLIENT_SECRET=dev_client_secretNODE_ENV=production
LOG_LEVEL=info
GOOGLE_APP_SCRIPT_API_CLIENT_ID=prod_client_id
GOOGLE_APP_SCRIPT_API_CLIENT_SECRET=prod_client_secretThe OAuth helper automatically caches access tokens in memory and refreshes them as needed.
For multiple operations, consider batching requests where possible:
// Instead of multiple individual calls
const results = await Promise.all([
tool1(args1),
tool2(args2),
tool3(args3)
]);Google Apps Script API has rate limits. The tools include automatic retry logic with exponential backoff.
Never commit .env files to version control
Use different OAuth apps for development and production
Regularly rotate OAuth credentials
Monitor OAuth app usage in Google Cloud Console
Use least-privilege OAuth scopes
Add only necessary test users to your OAuth app
Monitor script execution logs for unauthorized access
Implement logging for all API calls
Run the MCP server in a secure environment
Use HTTPS for production deployments
Implement proper firewall rules
Monitor network traffic for anomalies
# Start the MCP server
npm start
# Start with SSE support
npm run start-sse
# Start with debug logging
npm run debug
# Start SSE with debug logging
npm run debug-sse
# List all available tools and their descriptions
npm run list-tools
# Test OAuth authentication
npm run test-oauth
# Set up or refresh OAuth tokens
npm run setup-oauth
# Test logging functionality
npm run test-loggingnpm run list-toolsExample output:
Available Tools:
Google Apps Script API:
script-projects-create
Description: Create a new Google Apps Script project
Parameters:
- title (required): The title of the new script project
- parentId (optional): The ID of the parent project
script-projects-get
Description: Get metadata of a Google Apps Script project
Parameters:
- scriptId (required): The ID of the script project to retrieve
- fields (optional): Specific fields to include in response
[... additional parameters ...]Visit Postman MCP Generator
Select new API requests for Google Apps Script or other APIs
Generate a new MCP server
Copy new tool files into your existing tools/ folder
Update tools/paths.js to include new tool references
Restart your MCP server
GitHub Issues: Report bugs and request features
Postman Discord: Join the #mcp-lab channel in Postman Discord
Documentation: Visit Postman MCP Generator for updates
Contributions are welcome! Please:
Fork the repository
Create a feature branch
Add tests for new functionality
Submit a pull request
This project is licensed under the MIT License. See the LICENSE file for details.
Get metrics data for Google Apps Script projects.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Selector specifying which fields to include in a partial response. | |
| scriptId | Yes | The ID of the script project. | |
| deploymentId | Yes | The ID of the deployment to filter metrics. | |
| metricsGranularity | Yes | The granularity of the metrics data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not warn about rate limits, authorization requirements, response format, pagination, or potential errors. The description is too sparse to inform the agent about side effects or safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is easy to parse. It does not waste words, but it is somewhat under-specified for the complexity of the tool (4 required parameters). Still, for a simple 'get' operation, the length is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description must explain the behavior and return value, but it does not. The tool has 4 required parameters and no output schema, leaving the agent without information about response structure or how metrics are returned. This is inadequate for a tool that likely returns a complex metrics payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a clear description (e.g., scriptId, deploymentId, metricsGranularity, fields). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate. The 'fields' parameter is explained as a partial response selector, which is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get metrics data') and the resource ('Google Apps Script projects'). It is specific enough to distinguish from sibling tools, none of which are metrics-focused. However, 'metrics data' is somewhat generic and does not specify the type of metrics (e.g., execution or error metrics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, use cases, or situations where this tool is preferred. Sibling tools are listed but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the web app /exec URL(s) and access config for a script project's deployments.
| Name | Required | Description | Default |
|---|---|---|---|
| scriptId | Yes | The ID of the script project. | |
| deploymentId | No | Optional specific deployment to inspect. If omitted, all deployments are scanned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation, which is helpful, but the description does not disclose potential side effects, required permissions, or what happens when no deployments exist. It lacks explicit safety or edge-case context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose without any filler. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters and no output schema, but the description does not explain the return format or what 'access config' entails. It lacks edge-case information such as behavior when no deployments are found. While complete for a basic read tool, it could be more self-sufficient given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters fully described in the input schema. The tool description itself does not add any extra parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets web app /exec URL(s) and access config for deployments, which is a specific verb and resource. It distinguishes itself from sibling tools like script_projects_deployments_list or script_projects_deployments_get by focusing on the URL and config rather than general deployment info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: use this tool when you need the web app URL or access config for a deployment. However, there is no explicit guidance on when to prefer this over publish_web_app or other deployment-related tools, nor any exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List information about a script's executed processes.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Filter by process types. | |
| endTime | No | Filter by end time. | |
| pageSize | No | The number of processes to return per page. | |
| scriptId | Yes | The ID of the script to list processes for. | |
| statuses | No | Filter by process statuses. | |
| pageToken | No | Token for pagination. | |
| startTime | No | Filter by start time. | |
| deploymentId | No | Filter by deployment ID. | |
| functionName | No | Filter by function name. | |
| userAccessLevels | No | Filter by user access levels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself, but it only states the action. It does not mention pagination, filtering behavior, authentication needs, or what happens with invalid inputs. This is a read operation but that is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded, which is concise. However, given the tool has 10 parameters and no output schema, the brevity borders on under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 10 parameters, no output schema, and no annotations. The description provides only the basic action, omitting return value structure, pagination defaults, and relationships with sibling tools, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 10 parameters. The description adds no additional meaning beyond the generic action, which is the baseline expected when schema covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('script's executed processes'), making the core action clear. However, it does not differentiate this tool from the similarly named sibling 'script_processes_list', so it loses a point for missing sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'script_processes_list' or 'recent_executions'. It does not state any prerequisites or intended scenarios, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search the user's Google Apps Script projects (via Drive). Returns each project's scriptId and name. Use this to discover a scriptId when you don't already have one. Requires a Drive scope; re-run OAuth setup if it reports insufficient scopes.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Results per page (max 100, default 50). | |
| pageToken | No | Pagination token from a previous response. | |
| nameContains | No | Only return projects whose name contains this text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It discloses the auth requirement (Drive scope, OAuth re-run) and the return value (scriptId and name), which adds useful context. However, it does not cover other behavioral aspects like pagination behavior, result ordering, or potential errors beyond scope issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and every sentence adds value (purpose, return value, use case, auth note). No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description covers the core purpose, return values, a concrete use case, and auth prerequisites. The schema fills in parameter details. The only missing element might be an explicit note about pagination or defaults, but the schema already provides those, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (pageSize, pageToken, nameContains) with clear descriptions. The tool description does not add parameter-specific details beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists or searches the user's Google Apps Script projects, specifies the return values (scriptId and name), and distinguishes it as the discovery tool for scriptIds. This is a specific verb+resource that stands apart from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('Use this to discover a scriptId when you don't already have one') and mentions the required Drive scope with OAuth re-run. It does not explicitly mention when not to use it or alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a Google Apps Script web app in one step: optionally update content, create a new version, and repoint an existing deployment to it (deployment URL stays stable).
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Optional project files to write before publishing (Apps Script content format: { name, type, source }). If omitted, the current saved content is published. | |
| scriptId | Yes | The ID of the script project. | |
| description | No | Description for the new version and deployment. | |
| deploymentId | Yes | The ID of the existing deployment to repoint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adequately discloses the key behavioral traits: optional content update, new version creation, repointing of an existing deployment, and stable deployment URL. It notably explains the 'one-step' side effect of combining actions, though it does not mention possible side effects like OAuth scopes or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the primary action and efficiently packs the workflow steps and the stable-URL guarantee. No wasted words, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity, no output schema, and no annotations, so the description should cover return values or errors. It explains the workflow thoroughly and notes the stable URL, but omits what the tool returns (e.g., deployment info) and potential failure conditions. This leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (100% coverage), so the description adds little parameter-level meaning. It mentions 'optionally update content' which maps to the optional files parameter, but does not elaborate beyond the schema. This meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Publish a Google Apps Script web app in one step' and enumerates the specific sub-steps (optionally update content, create a new version, repoint deployment). It distinguishes this high-level composite tool from sibling tools like script_projects_deployments_update or script_projects_versions_create by framing it as a one-shot publish operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one step' implies when to use this tool—for a combined publish workflow—and the description specifies what it does without needing separate calls. However, it does not explicitly state when to choose this over individual sibling operations, so it lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent executions of an Apps Script project (function, status, start time, duration). Optionally filter to failures. Uses execution metadata — no extra scope, and does not include console.log output.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Max executions to return (API max 50, default 20). | |
| scriptId | Yes | The ID of the script project. | |
| pageToken | No | Pagination token from a previous response. | |
| functionName | No | Filter to executions of a specific function. | |
| onlyFailures | No | Only return failed / timed-out / canceled executions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds behavioral context by stating it uses execution metadata, requires no extra scope, and excludes console.log output. However, it does not disclose default ordering, pagination behavior, or potential errors, leaving some burden unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the core purpose and followed by a useful filter and a key limitation. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool without an output schema, the description specifies the returned fields, the failure filter, and a notable limitation, covering the essential context. It does not discuss pagination semantics, but the pageToken parameter partially covers that; overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already describes all five parameters, and the description adds only the filter-for-failures option (matching onlyFailures) without syntax details. It does not compensate further, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List recent executions of an Apps Script project' with a specific verb and resource, and enumerates returned fields (function, status, start time, duration). This distinguishes it from execution-related siblings like script_run (which runs) and process-listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that it can optionally filter to failures and explicitly states it does not include console.log output, which helps agents decide when to use this tool. It does not explicitly name alternatives or exclusion conditions beyond the log limitation, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List processes for a Google Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | The types of processes to filter. | |
| fields | No | Selector specifying which fields to include in a partial response. | |
| endTime | No | The end time for filtering processes. | |
| pageSize | No | The number of processes to return per page. | |
| scriptId | Yes | The ID of the script to filter processes. | |
| statuses | No | The statuses to filter processes. | |
| pageToken | No | Token for pagination. | |
| startTime | No | The start time for filtering processes. | |
| projectName | No | The project name to filter processes. | |
| deploymentId | No | The deployment ID to filter processes. | |
| functionName | No | The name of the function to filter processes. | |
| userAccessLevels | No | User access levels to filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it simply states 'List processes' without explaining pagination, response format, or the meaning of 'processes' in this context. It adds no behavioral detail beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and target. Every word earns its place, with no redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 12 parameters, no output schema, and no annotations, yet the description provides minimal context. It does not clarify what 'processes' represents, how filtering works, or what the return structure looks like, making it insufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the semantics of all 12 parameters are already well-documented. The description itself adds no parameter-specific information, but the schema's thorough coverage justifies the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and the resource 'processes for a Google Apps Script project,' making its purpose unambiguous. However, it does not differentiate from the similar sibling tool 'list_script_processes,' so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_script_processes' or 'recent_executions.' The description offers no context, exclusions, or alternative suggestions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Google Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | The title of the new script project. | |
| parentId | Yes | The ID of the parent project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility. It only states the action without disclosing side effects, permission requirements, idempotency, or return behavior, making it insufficient for understanding the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, making it easy to parse and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple creation action, but with no output schema and no annotations, the description lacks information about the return value or any preconditions. For a create operation, this is a notable gap, so the description is not complete on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (title and parentId) with clear descriptions, achieving 100% coverage. The description adds no parameter-specific meaning, so it meets the baseline without further input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Google Apps Script project.' uses a specific verb (create) and names the resource (Google Apps Script project), distinguishing it from sibling tools that create deployments or versions. This is unambiguous and aligns with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any prerequisites or exclusions. It simply states the action with no context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a deployment of an Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| scriptId | Yes | The ID of the script to deploy. | |
| description | Yes | A description for the deployment. | |
| versionNumber | Yes | The version number of the script. | |
| manifestFileName | Yes | The name of the manifest file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'creates a deployment' without explaining side effects, prerequisites, return values, or error conditions. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a create operation with four required parameters and no output schema. The description provides no information about return values, prerequisites, or failure scenarios. An AI agent would struggle to understand what to expect after calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds no parameter-specific meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (creates) and the resource (a deployment of an Apps Script project), distinguishing it from sibling tools like delete or update deployments. It is specific enough, though it lacks scope details like requiring a version or manifest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as the need for an existing version, or when to prefer update or delete. The description simply states the action with no context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a deployment of an Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| scriptId | Yes | The ID of the script project. | |
| deploymentId | Yes | The ID of the deployment to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Delete a deployment' without elaborating on whether the operation is permanent, whether it can be undone, or any side effects on the Apps Script project. The verb 'Delete' hints at destruction, but no additional context is given about the consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Delete') and resource. Every word earns its place, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple deletion tool with two well-documented parameters, so the bar for completeness is lower. However, the description omits any caveats like 'This is irreversible' or 'Only works for inactive deployments.' While not severely incomplete, it leaves room for more behavioral context that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'scriptId' and 'deploymentId' clearly described. The tool description itself adds no extra parameter meaning, but the schema already fully defines the parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a deployment of an Apps Script project' uses a specific verb ('Delete') and resource ('deployment of an Apps Script project'). It clearly distinguishes this from sibling tools like script_projects_deployments_list, create, update, and get by indicating a destructive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention scenarios where deletion is appropriate, prerequisites, or warnings about using it instead of update or get. With many sibling tools, this lack of contextual guidance leaves the agent to infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a deployment of an Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| scriptId | Yes | The ID of the script project. | |
| deploymentId | Yes | The ID of the deployment to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get' implies a read operation, but the description doesn't explicitly state safety, response format, or error behavior, leaving the agent without enough information about what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no unnecessary words, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple get operation, and the schema covers parameters, but the lack of usage guidance and behavioral details reduces completeness to a minimal viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for scriptId and deploymentId, so the description adds no additional meaning. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'a deployment of an Apps Script project,' clearly distinguishing it from sibling tools like list, create, update, or delete. It is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as script_projects_deployments_list or get_web_app_url. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the deployments of an Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Selector specifying which fields to include in a partial response. | |
| pageSize | No | The number of deployments to return per page. | |
| scriptId | Yes | The ID of the script project. | |
| pageToken | No | Token for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'lists deployments' without mentioning pagination behavior, ordering, read-only nature, or any access requirements. Minimal information beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the action and object. It wastes no words and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity and full schema coverage, the description is minimally adequate but leaves gaps: it does not explain the return format, pagination details, or how it fits with sibling tools. Since there is no output schema, a slightly richer description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of all four parameters (fields, pageSize, scriptId, pageToken), so the baseline of 3 applies. The description adds no extra meaning or context about how the parameters interact or are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' and identifies the resource as 'deployments of an Apps Script project', making the operation clear. It implicitly distinguishes from siblings like deployments_get or deployments_delete, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over its siblings. The description only states what it does, leaving the agent to infer usage context from the tool name and parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates a deployment of an Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| scriptId | Yes | The ID of the script to update. | |
| deploymentId | Yes | The ID of the deployment to update. | |
| deploymentConfig | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'updates' without explaining permissions, whether it is destructive, idempotency, or what happens to existing deployment settings. The description adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action and object. It is concise and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema. It does not explain return values, side effects, or when to use it. The terse description is insufficient for a tool with nested parameters and potential update semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover the scriptId and deploymentId parameters, and the deploymentConfig object has nested property descriptions, giving 67% coverage. The description itself adds no parameter-level meaning, so the schema provides adequate semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Updates) and the resource (a deployment of an Apps Script project), distinguishing it from sibling tools like create, delete, list, and get for deployments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as create for new deployments or get for retrieval. There are no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata of a Google Apps Script project. OAuth authentication is handled automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Selector specifying which fields to include in a partial response. | |
| scriptId | Yes | The ID of the script project to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It does disclose that OAuth authentication is handled automatically, which is useful context. However, it does not describe return format, error behavior, or side effects, though 'Get' implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences that front-load the core purpose and then add a key behavioral detail. Every word earns its place, with no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata retrieval tool with full schema coverage and no output schema, the description is mostly complete. It states purpose and the OAuth handling, but could enhance completeness by clarifying what 'metadata' includes or when to prefer this over related content-fetching tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both parameters (scriptId and fields), so the description does not need to add parameter meaning. The baseline of 3 applies as the schema handles the semantics fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metadata of a Google Apps Script project, using the specific verb 'Get' and naming the resource. It distinguishes itself from sibling tools like script_projects_get_content, which retrieves content rather than metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention scenarios, exclusions, or sibling tools, leaving the agent to infer usage solely from the name and the fact it fetches metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the content of a Google Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Selector specifying which fields to include in a partial response. | |
| scriptId | Yes | The ID of the script project to retrieve content for. | |
| versionNumber | No | The version number of the script project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but only says 'Get the content'. It does not describe whether the operation is read-only in terms of side effects, requires any special auth, what happens if the script ID is invalid, or the structure of the returned content. The verb 'get' implies a read operation, but no explicit safety or behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence that clearly states the tool's action. It contains no redundant information and is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and all parameters documented in the schema. However, there is no output schema and no mention of what the returned content looks like (e.g., file list, JSON structure), which could leave an agent uncertain about the response format. The description meets the minimum need but lacks some contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (scriptId, versionNumber, fields) already has a clear description. The tool description adds no additional meaning beyond the schema, warranting the baseline score of 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'content of a Google Apps Script project', making its primary function clear. It implicitly differentiates from sibling tools like script_projects_get (which likely fetches metadata) via the word 'content', but does not explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives such as script_projects_get or update_script_content, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new version of a Google Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| scriptId | Yes | The ID of the script project. | |
| description | Yes | A description for the new version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a state-changing operation but does not mention side effects (e.g., version immutability), permissions required, or whether the project content is snapshotted at the current state. This is a notable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word earns its place, making it maximally concise while still being clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with two well-described parameters, the minimal description is usable, but it omits return value information (no output schema exists) and any caveats. This leaves some contextual gaps, making it merely adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (scriptId and description), achieving 100% coverage. The description adds no extra parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') with a concrete resource ('a new version of a Google Apps Script project'), clearly distinguishing it from listing or getting versions. It accurately and unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like script_projects_deployments_create or update_script_content. There is no mention of prerequisites or use cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a version of a Google Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Selector specifying which fields to include in a partial response. | |
| scriptId | Yes | The ID of the script project. | |
| versionNumber | Yes | The version number of the script project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get a version', which adds no context beyond the tool name itself. It does not mention read-only behavior, required permissions, rate limits, or what response format to expect, leaving the agent to infer safety and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant wording. It is front-loaded with the verb and resource, making it easy to parse quickly. No unnecessary details are included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation (a single get) and the rich schema documentation, the description is minimally viable. However, no output schema exists and the description does not explain what a 'version' entails or any contextual constraints (e.g., that version numbers are sequential), leaving some ambiguity for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all three parameters (scriptId, versionNumber, fields), so the schema already explains their meanings. The description adds no additional parameter semantics, but the baseline of 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb 'Get' and resource 'a version of a Google Apps Script project', which identifies the operation. However, it does not explicitly distinguish from sibling tools like script_projects_versions_list, though the singular 'a version' implies a specific retrieval rather than listing all versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention exclusions, prerequisites, or alternatives such as script_projects_versions_list or script_projects_get_content. Usage context is only implied by the tool name and description, which is insufficient per the rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the versions of a Google Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Selector specifying which fields to include in a partial response. | |
| pageSize | No | The number of versions to return per page. | |
| scriptId | Yes | The ID of the script project. | |
| pageToken | No | The token for the next page of results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but it does not mention that results are paginated (supported by pageSize/pageToken in the schema) or describe the response format. It also does not clarify whether the list includes version metadata only or full content details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'List the versions of a Google Apps Script project.' It is front-loaded with the verb and resource, contains no filler words, and every word adds value. This is an example of appropriate minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and full schema coverage, the description is minimally adequate for a basic listing operation. The agent can infer pagination from the schema's pageToken parameter, but the description does not explicitly state return structure or that this tool lists all versions in a paginated manner. It is complete enough for an experienced agent but lacks additional context for a novice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documentation covers all four parameters (fields, pageSize, scriptId, pageToken) with descriptions, so the baseline is 3. The description's text does not add any extra param-specific meaning beyond what the schema already provides, but it also does not need to since the coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'versions of a Google Apps Script project', making the tool's purpose unambiguous. It naturally distinguishes itself from sibling tools like script_projects_versions_get (single version) and script_projects_versions_create (creating versions), since listing is a different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only the action itself and gives no context about when to choose this tool over alternatives. There are no explicit usage scenarios, prerequisites, or exclusions. An agent stumbles in trying to decide between this and, say, script_projects_versions_get, because the description does not say 'use this to see all versions' or 'use the get tool for a specific version'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a function in a Google Apps Script project. The script must be deployed as an API executable and share the calling OAuth client's Cloud project.
| Name | Required | Description | Default |
|---|---|---|---|
| devMode | No | Run the latest saved (HEAD) code instead of the deployed version. Only works for the script owner. | |
| scriptId | Yes | The ID of the script to run. | |
| parameters | No | Parameters to pass to the function (JSON-compatible values). | |
| functionName | Yes | The name of the function to execute. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only mentions deployment prerequisites, not the potential side effects of running arbitrary code, the return value, or any safety considerations. This is a significant gap for a tool that executes user-defined functions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, and the second adds a crucial prerequisite. No words are wasted, and every sentence carries meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the run returns. It doesn't mention the return value or error behavior. It also omits the devMode caveat (which only works for the script owner) from the description, though it's in the schema. For a tool that executes arbitrary code, the lack of return-value and side-effect information leaves the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 4 parameters with 100% coverage, so the description doesn't need to add parameter details. It adds no extra meaning beyond the schema, which earns a baseline score of 3 per the guidelines. The description ties parameters to the function invocation but lacking additional nuance keeps it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a function in a Google Apps Script project', using a specific verb and resource. This distinctly identifies the action from sibling tools that manage deployments, versions, or content, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by stating the prerequisite: 'The script must be deployed as an API executable and share the calling OAuth client's Cloud project.' This helps the agent determine if the tool is applicable. It doesn't explicitly mention alternatives, but the unique nature of running a function makes alternatives implicit, so this is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates the content of a specified Google Apps Script project.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | The files to be updated in the script project. | |
| scriptId | Yes | The ID of the script project to update. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'updates the content' but does not reveal whether this replaces all files, requires specific permissions, is reversible, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant or extraneous information. It is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is thin. It does not explain whether the update is a full replacement or partial, what the response looks like, or any required permissions, leaving the agent without adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters (scriptId and files), and the tool description adds no additional parameter semantics. The baseline of 3 is appropriate because the schema already provides the needed meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Updates') and the target ('content of a specified Google Apps Script project'). This distinguishes it from sibling tools like script_projects_get_content (reads) and script_projects_deployments_update (updates deployments), though it could be more explicit about the involvement of files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as get_content for reading or deployments_update for updating deployments, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0get_script_metricsget_web_app_urllist_script_processeslist_script_projectspublish_web_apprecent_executionsscript_processes_listscript_projects_createscript_projects_deployments_createscript_projects_deployments_deletescript_projects_deployments_getscript_projects_deployments_listscript_projects_deployments_updatescript_projects_getscript_projects_get_contentscript_projects_versions_createscript_projects_versions_getscript_projects_versions_listscript_runupdate_script_contentSeveral tools have overlapping purposes, especially 'list_script_processes' and 'script_processes_list', which appear to be duplicates with nearly identical descriptions. Additionally, 'recent_executions' overlaps with these process-listing tools, making it ambiguous which tool to use for execution history. The remaining tools are more distinct, but the confusion between these execution-related tools lowers the disambiguation score.
The tool names follow a mix of conventions: some use 'script_projects_{resource}_{action}' (e.g., script_projects_deployments_list), while others use verb-first names like 'list_script_projects' and 'update_script_content'. There are also inconsistent member names for similar operations, such as 'list_script_processes' vs. 'script_processes_list', and non-patterned names like 'publish_web_app' and 'recent_executions'. This lack of a consistent naming scheme makes it harder for an agent to predict tool names.
With 20 tools, the server covers a broad domain including project management, deployments, versions, execution monitoring, and publishing. While the count is on the heavier side, most tools serve distinct purposes, and the scope justifies the number. However, the presence of duplicate or near-duplicate process-listing tools suggests a few could be consolidated to trim the count.
The tool surface provides comprehensive CRUD coverage for projects, deployments, and versions, along with running and monitoring scripts. Essential operations are present, such as create/get/list/update/delete for deployments, create/list/get for versions, and script_run for execution. Minor gaps exist, such as no tool for updating project metadata or managing triggers, but core workflows are well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Streamable HTTP MCP server for Google Calendar and Sheets with OAuth login.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/andyconley/google-appscript-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
