Which integrations are available for this server?

Enables automation and workflow integration by allowing AI agents to interact with and execute Google Apps Script. Provides tools for spreadsheet operations, data engineering, and dataset management, allowing AI agents to read, write, and analyze data within Google Sheets.

How do I use GAS MCP Server Advanced?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GAS MCP Server Advanced Create a pivot table and summary chart for the sales data in my current sheet" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

GAS MCP Server Advanced

by devfinprojects

Overview Schema Related Servers Score Discussions

TypeScript

Remote

flowchart LR
    subgraph "🤖 AI Agents"
        A[MCP Client]
    end
    
    subgraph "🔷 MCP Server"
        B[Tool Registry]
        C[Rate Limiter]
        D[Context Engine]
        E[Security Layer]
    end
    
    subgraph "📊 Google APIs"
        F[Sheets API]
        G[Apps Script]
        H[Drive API]
    end
    
    A -->|JSON-RPC| B
    B --> C --> D --> E --> F
    E --> G
    E --> H
    
    style A fill:#1a1a2e,stroke:#00d9ff,color:#fff
    style B fill:#16213e,stroke:#a855f7,color:#fff
    style C fill:#0f3460,stroke:#22c55e,color:#fff
    style D fill:#1a1a2e,stroke:#f59e0b,color:#fff
    style E fill:#0f0f23,stroke:#ef4444,color:#fff
    style F fill:#1e3a5f,stroke:#3b82f6,color:#fff
    style G fill:#1e3a5f,stroke:#3b82f6,color:#fff
    style H fill:#1e3a5f,stroke:#3b82f6,color:#fff

⭐ Star us on GitHub	📖 Read the Docs	💬 Join Discord	🐛 Report Issues

✨ Features

Context Intelligence

Token estimation • Compression • Semantic search • Dataset management

100K+ tokens supported

100+ MCP Tools

Spreadsheet ops • AI analysis • Automation workflows • Data pipelines

Comprehensive coverage

Self-Healing

Circuit breaker • Auto-retry • Error recovery • Health checks

99.9% uptime

Adaptive Rate Limiting

Per-agent limits • Per-API quotas • Sliding windows • Backoff strategy

Smart throttling

Enterprise Security

RBAC • AES-256 encryption • OAuth2 • Audit logging • SOC2 ready

Bank-grade protection

Complete Observability

Metrics • Tracing • Health checks • Alerting • Audit logs

Full visibility

Related MCP server: Google Sheets MCP

🏗️ Architecture

╔═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗
║                                          GOOGLE APPS SCRIPT MCP SERVER                                              ║
║                                                  HIGH-LEVEL ARCHITECTURE                                             ║
╠═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╣
║                                                                                                                                 ║
║      ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐   ║
║      │                                                    🤖 MCP CLIENT (AI AGENT)                                   │   ║
║      │                                                         ┌──────────────┐                                       │   ║
║      │                                                         │ JSON-RPC 2.0 │                                       │   ║
║      │                                                         │  SSE Stream  │                                       │   ║
║      │                                                         └──────┬───────┘                                       │   ║
║      └───────────────────────────────────────────────────────────────┼───────────────────────────────────────────────┘   ║
║                                                                  │                                                    ║
║                                                                  ▼                                                    ║
║      ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐   ║
║      │                                                   🔷 MCP SERVER                                                │   ║
║      │  ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────┐  │   ║
║      │  │                                     📦 SERVER MANAGEMENT LAYER                                          │  │   ║
║      │  │  ┌────────────────┐     ┌───────────────────┐     ┌────────────────────────┐     ┌─────────────────┐   │  │   ║
║      │  │  │   ⚙️ Config   │     │   🖥️ Server        │     │     🗂️ Tool            │     │   🔒 Auth       │   │  │   ║
║      │  │  │   Manager     │     │   Manager          │     │     Registry          │     │   Manager       │   │  │   ║
║      │  │  └────────────────┘     └───────────────────┘     └────────────────────────┘     └─────────────────┘   │  │   ║
║      │  └──────────────────────────────────────────────────────────────────────────────────────────────────────────┘  │   ║
║      │                                                                                                                 │   ║
║      │  ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────┐  │   ║
║      │  │                                🧠 CONTEXT INTELLIGENCE LAYER                                              │  │   ║
║      │  │  ┌────────────────┐     ┌───────────────────┐     ┌────────────────────────┐     ┌─────────────────┐   │  │   ║
║      │  │  │   📊 Context  │     │   🎯 Token        │     │     💾 Dataset         │     │   🗄️ Embedding │   │  │   ║
║      │  │  │   Manager     │     │   Estimator       │     │     Store              │     │   Store         │   │  │   ║
║      │  │  └────────────────┘     └───────────────────┘     └────────────────────────┘     └─────────────────┘   │  │   ║
║      │  │  ┌────────────────┐     ┌───────────────────┐     ┌────────────────────────┐     ┌─────────────────┐   │  │   ║
║      │  │  │   🗜️ Compress │     │   💨 Memory      │     │     🔍 Semantic        │     │   📐 Truncator │   │  │   ║
║      │  │  │   or          │     │   Cache          │     │     Search             │     │                 │   │  │   ║
║      │  │  └────────────────┘     └───────────────────┘     └────────────────────────┘     └─────────────────┘   │  │   ║
║      │  └──────────────────────────────────────────────────────────────────────────────────────────────────────────┘  │   ║
║      │                                                                                                                 │   ║
║      │  ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────┐  │   ║
║      │  │                                     🔌 MIDDLEWARE LAYER                                                     │  │   ║
║      │  │  ┌────────────────┐     ┌───────────────────┐     ┌────────────────────────┐     ┌─────────────────┐   │  │   ║
║      │  │  │   ⏱️ Rate     │     │   🔄 Interceptor  │     │     ⚠️ Error           │     │   📝 Prompt    │   │  │   ║
║      │  │  │   Limiter     │     │   Chain           │     │     Handler           │     │   Manager       │   │  │   ║
║      │  │  └────────────────┘     └───────────────────┘     └────────────────────────┘     └─────────────────┘   │  │   ║
║      │  └──────────────────────────────────────────────────────────────────────────────────────────────────────────┘  │   ║
║      │                                                                                                                 │   ║
║      │  ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────┐  │   ║
║      │  │                                     🔐 SECURITY LAYER                                                       │  │   ║
║      │  │  ┌────────────────┐     ┌───────────────────┐     ┌────────────────────────┐     ┌─────────────────┐   │  │   ║
║      │  │  │   🛡️ Access  │     │   🔏 Encryption  │     │     🔎 Threat          │     │   ✅ Compliance │   │  │   ║
║      │  │  │   Control     │     │                   │     │     Detection          │     │                 │   │  │   ║
║      │  │  └────────────────┘     └───────────────────┘     └────────────────────────┘     └─────────────────┘   │  │   ║
║      │  └──────────────────────────────────────────────────────────────────────────────────────────────────────────┘  │   ║
║      │                                                                                                                 │   ║
║      │  ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────┐  │   ║
║      │  │                                    📈 OBSERVABILITY LAYER                                                  │  │   ║
║      │  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌───────────┐  ┌───────────┐  ┌────────────────┐           │  │   ║
║      │  │  │  📊      │  │  ❤️       │  │  🔍      │  │   📋      │  │   🔔       │  │    📜         │           │  │   ║
║      │  │  │ Metrics  │  │ Health   │  │ Tracing  │  │  Audit    │  │ Alerting   │  │    Logging    │           │  │   ║
║      │  │  └──────────┘  └──────────┘  └──────────┘  └───────────┘  └───────────┘  └────────────────┘           │  │   ║
║      │  └──────────────────────────────────────────────────────────────────────────────────────────────────────────┘  │   ║
║      │                                                                                                                 │   ║
║      │  ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────┐  │   ║
║      │  │                                    💚 SELF-HEALING LAYER                                                   │  │   ║
║      │  │  ┌────────────────┐     ┌───────────────────┐     ┌────────────────────────┐                          │  │   ║
║      │  │  │   🔄 Circuit │     │   🔁 Auto        │     │     🩺 Health          │                          │  │   ║
║      │  │  │   Breaker    │     │   Retry         │     │     Monitor            │                          │  │   ║
║      │  │  └────────────────┘     └───────────────────┘     └────────────────────────┘                          │  │   ║
║      │  └──────────────────────────────────────────────────────────────────────────────────────────────────────────┘  │   ║
║      └───────────────────────────────────────────────────────────────────────────────────────────────────────────────┘   ║
║                                                                  │                                                    ║
║                                                                  ▼                                                    ║
║      ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────┐   ║
║      │                                                📱 GOOGLE APIS                                                │   ║
║      │   ┌──────────────────────┐     ┌────────────────────────┐     ┌─────────────────────────────────────────┐    │   ║
║      │   │       📊            │     │        📜              │     │              📁                       │    │   ║
║      │   │    Sheets API       │     │    Apps Script API     │     │            Drive API                   │    │   ║
║      │   └──────────────────────┘     └────────────────────────┘     └─────────────────────────────────────────┘    │   ║
║      └───────────────────────────────────────────────────────────────────────────────────────────────────────────────┘   ║
╚═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝

Request Flow

┌──────────┐     ┌───────────────┐     ┌────────────────┐     ┌──────────────┐     ┌────────────────┐
│  Client  │────►│     Tool      │────►│      Rate     │────►│    Context   │────►│     Auth       │
│ Request  │     │    Registry   │     │    Limiter    │     │    Engine    │     │    Layer       │
└──────────┘     └───────────────┘     └────────────────┘     └──────────────┘     └───────┬────────┘
                                                                                                │
      ┌───────────────────────────────────────────────────────────────────────────────────────┘
      │
      ▼
┌──────────────┐     ┌────────────────┐     ┌─────────────┐
│   Google     │────►│   Response     │────►│    Client   │
│     APIs     │     │    Builder     │     │   Response  │
└──────────────┘     └────────────────┘     └─────────────┘

Circuit Breaker State Machine

                            ┌───────────────────┐
                            │   🔴 CLOSED       │
                            │    (Normal Ops)   │
                            └─────────┬─────────┘
                                      │
                     failures > threshold
                                      │
                                      ▼
                            ┌───────────────────┐
                            │   🟠 OPEN STATE   │
                            │ (Rejecting Reqs)  │
                            └─────────┬─────────┘
                                      │
                           timer expires
                                      │
                                      ▼
                            ┌───────────────────┐
                            │  🟡 HALF-OPEN     │
                            │   (Test Mode)     │
                            └─────────┬─────────┘
                                      │
           ┌──────────────────────────┼──────────────────────────┐
           │                          │                          │
      success ✓                   success ✓                failure ✗
           │                          │                          │
           ▼                          ▼                          ▼
    ┌─────────────┐           ┌─────────────┐           ┌─────────────┐
    │   CLOSED    │           │   CLOSED    │           │    OPEN     │
    │   ✅        │           │   ✅        │           │     🔴      │
    └─────────────┘           └─────────────┘           └─────────────┘

🚀 Quick Start

Prerequisites

Installation

# Clone the repository
git clone https://github.com/devfinprojects/GAS-MCPSERVER.git
cd GAS-MCPSERVER

# Install dependencies
npm install

# Build the project
npm run build

Environment Setup

# Copy example environment file
cp env.example .env

# Edit configuration
#nano .env  # Linux/Mac
#notepad .env  # Windows

🔧 Configuration

Variable	Description	Default	Required
`GOOGLE_CREDENTIALS_PATH`	Path to OAuth JSON	`./credentials.json`	✅ Yes
`PORT`	HTTP server port	`3000`	❌ No
`LOG_LEVEL`	Logging verbosity	`info`	❌ No
`RATE_LIMIT_REQUESTS_PER_MINUTE`	Rate limit per minute	`60`	❌ No
`CONTEXT_MAX_TOKENS`	Max context tokens	`100000`	❌ No
`ENABLE_SELF_HEALING`	Enable circuit breaker	`true`	❌ No
`ENABLE_METRICS`	Enable Prometheus metrics	`false`	❌ No
`ENABLE_TRACING`	Enable distributed tracing	`false`	❌ No
`ENABLE_AUDIT_LOGGING`	Enable audit logs	`true`	❌ No
`CIRCUIT_BREAKER_THRESHOLD`	Failure threshold	`5`	❌ No
`CIRCUIT_BREAKER_TIMEOUT`	Reset timeout (ms)	`30000`	❌ No

🛠️ Tools Reference

╔══════════════════════════════════════════════════════════════════════════════════════════════════════════╗
║                                    100+ MCP TOOLS BREAKDOWN                                             ║
╠══════════════════════════════════════════════════════════════════════════════════════════════════════════╣
║                                                                                                          ║
║   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐             ║
║   │      🤖      │  │      ⚡      │  │      📊     │  │      🧠     │  │      📝      │             ║
║   │      AI      │  │  AUTOMATION  │  │ DATA ENGR   │  │   CONTEXT   │  │ CODE QUALITY │             ║
║   │    TOOLS     │  │    TOOLS     │  │    TOOLS    │  │    TOOLS    │  │    TOOLS     │             ║
║   │              │  │              │  │             │  │             │  │              │             ║
║   │ • Analysis   │  │ • Jobs       │  │ • ETL       │  │ • Datasets  │  │ • Analysis   │             ║
║   │ • Anomaly    │  │ • Workflows  │  │ • Import    │  │ • Query     │  │ • Review     │             ║
║   │ • Patterns   │  │ • Webhooks   │  │ • Export    │  │ • Control   │  │ • Doc Gen    │             ║
║   │ • Transform  │  │ • Triggers   │  │ • Mapping   │  │             │  │ • Test Gen   │             ║
║   │ • NLQ       │  │ • Notifs     │  │ • Pipeline  │  │             │  │ • Types      │             ║
║   │ • Recommen-  │  │ • Scheduled  │  │ • Validation│  │             │  │              │             ║
║   │   dations   │  │              │  │             │  │             │  │              │             ║
║   │              │  │              │  │             │  │             │  │              │             ║
║   │    35+       │  │     25+      │  │     25+     │  │     15+     │  │     25+      │             ║
║   └──────────────┘  └──────────────┘  └──────────────┘  └──────────────┘  └──────────────┘             ║
║                                                                                                          ║
╚══════════════════════════════════════════════════════════════════════════════════════════════════════════╝

🤖 AI Analysis Tools (35+ tools)

Tool Category	Tools	Description
📈 Analysis	8 tools	Data analysis, column analysis, summaries
🔍 Anomaly Detection	4 tools	Outlier detection, unusual values
🔁 Pattern Recognition	5 tools	Patterns, sequences, cycles, distributions
🔮 Recommendations	4 tools	Improvements, chart suggestions
🧹 Transformation	5 tools	Data cleaning, reshaping, aggregation
💬 Natural Language	5 tools	NL to spreadsheet, formula generation

Analysis Tools

Tool Name	Parameters	Return Type	Example
`analyze_sheet_data`	`spreadsheetId, range`	`{ analysis }`	`{ "name": "analyze_sheet_data", "args": { "spreadsheetId": "abc" } }`
`analyze_column`	`spreadsheetId, range, column`	`{ stats }`	`{ "name": "analyze_column", "args": { "spreadsheetId": "abc", "column": "A" } }`
`get_data_summary`	`spreadsheetId`	`{ summary }`	`{ "name": "get_data_summary", "args": { "spreadsheetId": "abc" } }`

Anomaly Detection

Tool Name	Parameters	Return Type	Example
`detect_outliers`	`spreadsheetId, range, method`	`{ outliers }`	`{ "name": "detect_outliers", "args": { "spreadsheetId": "abc" } }`
`analyze_anomalies`	`spreadsheetId, timeRange`	`{ anomalies }`	`{ "name": "analyze_anomalies", "args": { "spreadsheetId": "abc" } }`
`find_unusual_values`	`spreadsheetId, column`	`{ values }`	`{ "name": "find_unusual_values", "args": { "spreadsheetId": "abc" } }`

Pattern Recognition

Tool Name	Parameters	Return Type	Example
`detect_patterns`	`spreadsheetId, range`	`{ patterns }`	`{ "name": "detect_patterns", "args": { "spreadsheetId": "abc" } }`
`find_sequences`	`spreadsheetId, column`	`{ sequences }`	`{ "name": "find_sequences", "args": { "spreadsheetId": "abc" } }`
`detect_cycles`	`spreadsheetId, range`	`{ cycles }`	`{ "name": "detect_cycles", "args": { "spreadsheetId": "abc" } }`

Transformation

Tool Name	Parameters	Return Type	Example
`clean_sheet_data`	`spreadsheetId, rules`	`{ cleaned }`	`{ "name": "clean_sheet_data", "args": { "spreadsheetId": "abc" } }`
`transform_data`	`spreadsheetId, transforms`	`{ result }`	`{ "name": "transform_data", "args": { "spreadsheetId": "abc" } }`
`reshape_data`	`spreadsheetId, pivotConfig`	`{ reshaped }`	`{ "name": "reshape_data", "args": { "spreadsheetId": "abc" } }`

Natural Language Query

Tool Name	Parameters	Return Type	Example
`nl_to_spreadsheet_action`	`query, spreadsheetId`	`{ action }`	`{ "name": "nl_to_spreadsheet_action", "args": { "query": "add column" } }`
`generate_formula`	`description, context`	`{ formula }`	`{ "name": "generate_formula", "args": { "description": "sum of column" } }`
`query_data_nl`	`query, spreadsheetId`	`{ results }`	`{ "name": "query_data_nl", "args": { "query": "sales > 1000" } }`

⚡ Automation Tools (25+ tools)

Tool Category	Tools	Description
📅 Job Scheduler	8 tools	Create, manage, trigger scheduled jobs
🔀 Workflows	7 tools	Multi-step automation workflows
🪝 Webhooks	9 tools	Event-driven triggers
⏰ Triggers	6 tools	Spreadsheet trigger management
🔔 Notifications	12 tools	Alerts and notifications

Job Scheduler

Tool Name	Parameters	Return Type
`create_scheduled_job`	`name, schedule, action`	`{ jobId }`
`list_scheduled_jobs`	`filters`	`{ jobs }`
`get_scheduled_job`	`jobId`	`{ job }`
`update_scheduled_job`	`jobId, updates`	`{ updated }`
`delete_scheduled_job`	`jobId`	`{ deleted }`
`trigger_job_now`	`jobId`	`{ triggered }`
`pause_scheduled_job`	`jobId`	`{ paused }`
`resume_scheduled_job`	`jobId`	`{ resumed }`

Workflows

Tool Name	Parameters	Return Type
`create_workflow`	`name, steps`	`{ workflowId }`
`list_workflows`	`filters`	`{ workflows }`
`get_workflow`	`workflowId`	`{ workflow }`
`run_workflow`	`workflowId, inputs`	`{ result }`
`stop_workflow`	`workflowId`	`{ stopped }`
`validate_workflow`	`workflow`	`{ valid }`

Webhooks

Tool Name	Parameters	Return Type
`register_webhook`	`url, events, secret`	`{ webhookId }`
`list_webhooks`	`filters`	`{ webhooks }`
`delete_webhook`	`webhookId`	`{ deleted }`
`test_webhook`	`webhookId`	`{ result }`
`enable_webhook`	`webhookId`	`{ enabled }`
`disable_webhook`	`webhookId`	`{ disabled }`

📊 Data Engineering Tools (25+ tools)

Tool Category	Tools	Description
🔄 ETL	5 tools	Extract, transform, load pipelines
📥 Import/Export	6 tools	CSV, JSON, batch operations
🗺️ Mapping	5 tools	Schema detection and mapping
📦 Pipeline	5 tools	Data pipeline management
✅ Validation	5 tools	Data quality and schema validation

ETL Tools

Tool Name	Parameters	Return Type
`extract_spreadsheet_data`	`spreadsheetId, range, options`	`{ data }`
`transform_data_batch`	`data, transforms`	`{ transformed }`
`load_to_spreadsheet`	`spreadsheetId, data, options`	`{ loaded }`
`run_etl_pipeline`	`config`	`{ result }`

Import/Export

Tool Name	Parameters	Return Type
`import_csv`	`url, spreadsheetId, options`	`{ imported }`
`export_csv`	`spreadsheetId, range, options`	`{ url }`
`import_json`	`data, spreadsheetId`	`{ imported }`
`export_json`	`spreadsheetId, range`	`{ data }`
`convert_format`	`source, targetFormat`	`{ converted }`
`batch_export`	`spreadsheetIds, format`	`{ results }`

Pipeline

Tool Name	Parameters	Return Type
`create_pipeline`	`config`	`{ pipelineId }`
`run_pipeline`	`pipelineId, inputs`	`{ result }`
`get_pipeline_status`	`pipelineId`	`{ status }`
`list_pipelines`	`filters`	`{ pipelines }`
`delete_pipeline`	`pipelineId`	`{ deleted }`

🧠 Context Tools (15+ tools)

Tool Category	Tools	Description
💾 Dataset	5 tools	Store, query, manage datasets
🔍 Query	4 tools	Search and retrieve context
🎛️ Control	6 tools	Context mode and optimization

Dataset Tools

Tool Name	Parameters	Return Type
`store_dataset`	`name, data, schema`	`{ datasetId }`
`query_dataset`	`datasetId, filters`	`{ rows }`
`list_datasets`	`filters`	`{ datasets }`
`delete_dataset`	`datasetId`	`{ deleted }`
`update_dataset`	`datasetId, data`	`{ updated }`

Query Tools

Tool Name	Parameters	Return Type
`semantic_search`	`query, datasetId`	`{ results }`
`get_dataset_stats`	`datasetId`	`{ stats }`
`get_token_usage`	`sessionId`	`{ usage }`
`dataset_exists`	`datasetId`	`{ exists }`

Context Control

Tool Name	Parameters	Return Type
`estimate_context_cost`	`spreadsheetId, range`	`{ tokens, cost }`
`set_context_mode`	`mode`	`{ mode }`
`get_context_config`	—	`{ config }`
`reset_session_tokens`	`sessionId`	`{ reset }`
`process_through_context`	`data, options`	`{ processed }`

📝 Code Quality Tools (25+ tools)

Tool Category	Tools	Description
📊 Analysis	5 tools	Code quality and complexity
👀 Review	3 tools	Automated code reviews
📚 Documentation	4 tools	JSDoc generation
🧪 Test Generation	3 tools	Unit test creation
✅ Type Checking	3 tools	Type validation

Analysis Tools

Tool Name	Parameters	Return Type
`analyze_code_quality`	`code, includeComplexity`	`{ metrics }`
`analyze_complexity`	`code`	`{ complexity }`
`analyze_dependencies`	`code`	`{ deps }`

Code Review

Tool Name	Parameters	Return Type
`perform_code_review`	`code`	`{ issues }`
`check_best_practices`	`code`	`{ violations }`
`suggest_improvements`	`code`	`{ suggestions }`

Documentation

Tool Name	Parameters	Return Type
`generate_jsdoc`	`code`	`{ docs }`
`generate_readme`	`project`	`{ readme }`
`update_comments`	`code`	`{ updated }`

Test Generation

Tool Name	Parameters	Return Type
`generate_unit_tests`	`code, framework`	`{ tests }`
`generate_integration_tests`	`code`	`{ tests }`
`generate_mocks`	`code`	`{ mocks }`

🔐 Security

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                              🔐 SECURITY ARCHITECTURE                                │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│   ┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐     │
│   │   🔒 OAuth2 │────►│   🛡️ RBAC   │────►│  🔏 AES-256 │────►│   📋 Audit  │     │
│   │  + Token    │     │  + Roles    │     │  Encryption │     │   Logging   │     │
│   │   Refresh   │     │  + Perms    │     │  + at Rest   │     │   + SOC2    │     │
│   └─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘     │
│                                                                                     │
└─────────────────────────────────────────────────────────────────────────────────────┘

✅ OAuth2 with automatic token refresh
✅ Role-Based Access Control (RBAC)
✅ AES-256 encryption at rest
✅ Comprehensive audit logging
✅ SOC2 and GDPR ready
✅ Threat detection and prevention

📈 Observability

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                           📈 OBSERVABILITY DASHBOARD                               │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│   ┌────────────────┐  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐│
│   │     📊        │  │      ❤️        │  │      🔍       │  │      🔔       ││
│   │   METRICS     │  │    HEALTH      │  │   TRACING     │  │   ALERTING    ││
│   │                │  │                │  │                │  │                ││
│   │ Prometheus    │  │  Liveness     │  │  Distributed  │  │  Rule-based   ││
│   │  Compatible   │  │  + Readiness  │  │    Spans      │  │  Notifications││
│   │                │  │                │  │                │  │                ││
│   │ • Request     │  │  • /health    │  │ • Jaeger      │  │ • Email       ││
│   │   Rate        │  │  • /ready      │  │   Compatible  │  │ • Slack       ││
│   │ • Latency     │  │  • Custom      │  │ • Custom      │  │ • Webhook     ││
│   │ • Errors      │  │    Checks      │  │   Tags        │  │ • PagerDuty   ││
│   └────────────────┘  └────────────────┘  └────────────────┘  └────────────────┘│
│                                                                                     │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐│
│   │                              📜 AUDIT LOGGING                                  ││
│   │                                                                                 ││
│   │  • Every API call logged    • User/agent tracking    • Immutable records    ││
│   │  • Queryable logs           • Export to SIEM          • Retention policies    ││
│   └─────────────────────────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────────────────────┘

💚 Self-Healing

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                          💚 SELF-HEALING MECHANISMS                                 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│   ┌────────────────┐  ┌────────────────┐  ┌────────────────┐                      │
│   │  🔄 CIRCUIT    │  │  🔁 AUTO       │  │  🩺 HEALTH    │                      │
│   │   BREAKER     │  │    RETRY       │  │   MONITOR     │                      │
│   │                │  │                │  │                │                      │
│   │  • Open       │  │  • Exponential │  │  • Periodic   │                      │
│   │  • Half-Open │  │    Backoff     │  │    Checks     │                      │
│   │  • Closed    │  │  • Max Attempts│  │  • Recovery   │                      │
│   │                │  │  • Jitter     │  │    Actions    │                      │
│   └────────────────┘  └────────────────┘  └────────────────┘                      │
│                                                                                     │
│   ═══════════════════════════════════════════════════════════════════════════════   │
│                                                                                     │
│   Configuration:                                                                     │
│   ┌─────────────────────────────────────────────────────────────────────────────┐   │
│   │  circuitBreaker: { failureThreshold: 5, resetTimeoutMs: 30000 }           │   │
│   │  maxRetries: 3, backoffMultiplier: 2, maxBackoffMs: 30000                  │   │
│   │  healthCheckInterval: 10000, recoveryThreshold: 3                          │   │
│   └─────────────────────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────────────────────┘

📦 Examples

import { createClient } from '@modelcontextprotocol/sdk';

const client = await createClient({
  serverUrl: 'http://localhost:3000',
  auth: { token: process.env.MCP_TOKEN }
});

// Create a new spreadsheet
const spreadsheet = await client.tools.create_spreadsheet({
  title: 'Sales Dashboard 2024',
  sheets: [
    { title: 'Q1 Data', rowCount: 1000, columnCount: 26 },
    { title: 'Q2 Data', rowCount: 1000, columnCount: 26 },
    { title: 'Summary', rowCount: 100, columnCount: 10 }
  ]
});

console.log(`Created: ${spreadsheet.spreadsheetId}`);

// Add data to the spreadsheet
await client.tools.update_values({
  spreadsheetId: spreadsheet.spreadsheetId,
  range: 'Q1 Data!A1',
  values: [
    ['Product', 'Revenue', 'Quantity'],
    ['Widget A', 15000, 150],
    ['Widget B', 23000, 230],
    ['Widget C', 18000, 180]
  ]
});

// Analyze spreadsheet data with AI
const analysis = await client.tools.analyze_sheet_data({
  spreadsheetId: 'abc123',
  range: 'Sales!A1:Z1000',
  includeCharts: true,
  generateInsights: true
});

console.log('Analysis Results:');
console.log(`- Total Rows: ${analysis.summary.rowCount}`);
console.log(`- Columns: ${analysis.summary.columns.join(', ')}`);
console.log(`- Insights: ${analysis.insights.length}`);

// Detect anomalies in the data
const anomalies = await client.tools.detect_outliers({
  spreadsheetId: 'abc123',
  range: 'Sales!B1:B1000',
  method: 'iqr',
  threshold: 1.5
});

console.log(`Found ${anomalies.outliers.length} outliers`);

// Create and run an ETL pipeline
const pipeline = await client.tools.create_pipeline({
  name: 'Daily Sales ETL',
  schedule: '0 2 * * *',  // 2 AM daily
  steps: [
    {
      id: 'extract',
      type: 'extract',
      source: {
        type: 'spreadsheet',
        spreadsheetId: 'source-id',
        range: 'Raw Data!A1:Z'
      }
    },
    {
      id: 'transform',
      type: 'transform',
      operations: [
        { type: 'filter', condition: { column: 'status', equals: 'active' } },
        { type: 'map', mappings: { old_col: 'new_col' } },
        { type: 'aggregate', groupBy: 'region', operations: ['sum', 'avg', 'count'] }
      ]
    },
    {
      id: 'load',
      type: 'load',
      destination: {
        type: 'spreadsheet',
        spreadsheetId: 'dest-id',
        sheet: 'Processed'
      }
    }
  ]
});

// Run the pipeline
const result = await client.tools.run_pipeline({
  pipelineId: pipeline.pipelineId,
  inputs: {}
});

console.log(`Processed ${result.rowsProcessed} rows in ${result.duration}ms`);

🤝 Contribution

# 1. Fork the repository
# 2. Clone your fork
git clone https://github.com/YOUR_USERNAME/GAS-MCPSERVER.git

# 3. Create a feature branch
git checkout -b feature/amazing-feature

# 4. Install dependencies
npm install

# 5. Make your changes
# 6. Run tests
npm test

# 7. Build the project
npm run build

# 8. Commit and push
git commit -m 'Add amazing feature'
git push origin feature/amazing-feature

# 9. Open a Pull Request

Development Scripts

Script	Description
`npm run build`	Compile TypeScript
`npm run start`	Start production server
`npm run dev`	Start development server
`npm test`	Run tests
`npm run test:watch`	Run tests in watch mode

📄 License

Available Tools

26 tools

add_data_validationC

Add data validation rules to a range

ParametersJSON Schema

Name	Required	Description
`spreadsheet_id`	Yes	The ID of the spreadsheet
`range`	Yes	A1 notation range
`rule`	Yes	Validation rule specification

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool's purpose but doesn't describe what happens when validation rules are added (e.g., whether existing data is validated, if rules are immediately enforced, error handling, or permission requirements). This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, side effects, or how validation rules behave in practice. Given the complexity of data validation rules and the lack of structured metadata, more context is needed for effective use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description doesn't add any meaningful context about parameter usage beyond what's in the schema (e.g., examples of validation rules, format of A1 notation, or how rules interact with existing data). Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Add data validation rules') and target ('to a range'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'create_protected_range' or 'update_cells_format' that also modify spreadsheet properties, leaving some ambiguity about when to choose this specific tool.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or how it differs from similar sibling tools like 'create_protected_range' or 'update_cells_format' that also apply constraints to spreadsheet ranges.

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

append_valuesB

Append values to the next available row in a sheet

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes	The ID of the spreadsheet
`sheet_name`	Yes	Name of the sheet to append to
`values`	Yes	2D array of values to append
`input_option`	No	How to interpret input	USER_ENTERED

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('append values') but doesn't cover critical aspects like permissions required, whether it's idempotent, error handling, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core action without unnecessary words. It directly conveys the tool's purpose without redundancy or fluff, 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.

Completeness3/5

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

Given the complexity of a mutation tool with no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, error cases, or output expectations. For a tool that modifies data, more context would be beneficial to ensure safe and correct usage.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what the schema provides, such as explaining the 'next available row' concept in relation to parameters. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('append values') and target ('next available row in a sheet'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'update_values' or 'batch_update_values', which might also modify sheet data, so it misses full sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like appending new rows versus updating existing ones, nor does it reference sibling tools like 'update_values' for modifications. Without such context, users must infer usage from the tool name alone.

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

batch_update_valuesC

Update multiple ranges in a single request

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes	The ID of the spreadsheet
`updates`	Yes	Array of range updates

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states this is an update operation (implying mutation) but doesn't disclose critical behavioral traits like required permissions, whether changes are reversible, rate limits, error handling, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the key information ('update multiple ranges') and adds useful context ('in a single request'). There is zero waste—every word earns its place.

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

Completeness2/5

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

Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., permissions, side effects) and doesn't explain return values or error cases. For a tool that modifies data, this leaves significant gaps for an AI agent.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters ('spreadsheet_id' and 'updates') and their nested properties. The description adds no additional meaning beyond what the schema provides, such as explaining the structure of 'updates' or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('update') and resource ('multiple ranges'), and specifies it's done 'in a single request', which distinguishes it from single-range updates. However, it doesn't explicitly differentiate from sibling tools like 'update_values' (which likely updates a single range), so it's not a perfect 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'update_values' for single-range updates or other batch operations, nor does it specify prerequisites or exclusions. Usage is implied by the name but not explicitly stated.

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

clear_valuesC

Clear values from a range of cells

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes	The ID of the spreadsheet
`range`	Yes	A1 notation range to clear

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the tool clears values, implying a destructive mutation, but lacks details on permissions needed, whether it's reversible, rate limits, or what happens to formatting (e.g., compared to 'update_cells_format'). This leaves significant behavioral gaps.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly.

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

Completeness2/5

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

Given the tool is a destructive mutation (clearing values) with no annotations and no output schema, the description is incomplete. It does not address critical context like error handling, return values, or side effects, which are essential for safe usage in a spreadsheet environment.

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

Parameters3/5

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

Schema description coverage is 100%, with both parameters ('spreadsheet_id' and 'range') well-documented in the schema. The description adds no additional meaning beyond implying the range is for clearing, which the schema already covers, so it meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('clear values') and target ('from a range of cells'), which is specific and unambiguous. However, it does not differentiate from sibling tools like 'delete_sheet' or 'find_and_replace', which could also involve removal operations, so it lacks sibling distinction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention when to choose 'clear_values' over 'delete_sheet' for removing content or 'update_values' for overwriting data, leaving usage context implied at best.

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

copy_sheetC

Copy a sheet to another spreadsheet or within the same spreadsheet

ParametersJSON Schema

Name	Required	Description
`source_spreadsheet_id`	Yes	Source spreadsheet ID
`source_sheet_id`	Yes	Sheet ID to copy
`destination_spreadsheet_id`	Yes	Destination spreadsheet ID
`new_title`	No	Optional new title for the copied sheet

TDQS

C2.9/5.0

Behavior2/5

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 states the tool copies a sheet but lacks details on permissions required, whether the operation is idempotent, error conditions (e.g., invalid IDs), or what happens to existing data. This leaves significant gaps in understanding the tool's behavior beyond the basic action.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without redundancy. It is front-loaded with the core action and scope, making it easy to parse quickly, with no wasted words or unnecessary elaboration.

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

Completeness2/5

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

Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is insufficient. It does not cover behavioral aspects like error handling, return values, or side effects, which are critical for an agent to invoke the tool correctly in a spreadsheet management context.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting all four parameters. The description adds no additional semantic context beyond implying copying within or across spreadsheets, which is already inferred from parameter names. Thus, it meets the baseline for high schema coverage without enhancing parameter understanding.

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

Purpose4/5

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

The description clearly states the action ('copy a sheet') and the target resources ('to another spreadsheet or within the same spreadsheet'), which is specific and unambiguous. However, it does not explicitly differentiate this tool from sibling tools like 'create_sheet' or 'update_sheet_properties', which could involve similar sheet operations, leaving room for minor confusion.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing access to source and destination spreadsheets, or compare it to sibling tools like 'create_sheet' for new sheets or 'update_sheet_properties' for modifications, 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.

create_protected_rangeC

Protect a range from editing

ParametersJSON Schema

Name	Required	Description
`spreadsheet_id`	Yes	The ID of the spreadsheet
`range`	Yes	A1 notation range to protect
`description`	No	Optional description
`editors`	No	Users/domains that can edit despite protection

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. 'Protect a range from editing' implies a mutation that restricts editing, but it doesn't disclose behavioral traits like required permissions, whether protection is reversible, what happens to existing data, or any rate limits. For a mutation tool with zero annotation coverage, this is inadequate.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded with the core functionality.

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

Completeness2/5

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

For a mutation tool with no annotations, no output schema, and complex nested parameters, the description is insufficient. It doesn't explain what happens after protection is applied, what the tool returns, or how the protection interacts with other spreadsheet operations. Given the complexity and lack of structured data, more context is needed.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description doesn't add any meaning beyond what's in the schema - it doesn't explain how protection works, what 'editors' exceptions mean in practice, or provide examples of range notation. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('protect') and target ('a range from editing'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'add_data_validation' or 'update_cells_format' which might also affect cell editing permissions.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'add_data_validation' that might serve similar protective functions, there's no indication of when this specific protection mechanism is appropriate or what prerequisites might be needed.

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

create_script_deploymentC

Create a new deployment for an Apps Script project

ParametersJSON Schema

Name	Required	Description	Default
`version_number`	Yes	Version number to deploy
`description`	Yes	Deployment description

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address permissions needed, whether deployments are reversible, rate limits, or what the tool returns (especially since there's no output schema). This leaves significant gaps 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.

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a deployment entails, how it relates to the script project, what happens on success/failure, or provide any behavioral context. The agent would lack critical information to use this tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents both parameters (version_number and description). The description adds no additional parameter context beyond what's in the schema, such as format expectations for version_number or typical content for description. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('Create') and target resource ('new deployment for an Apps Script project'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'list_script_deployments' or explain what distinguishes a deployment from other script-related operations.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, prerequisites (like needing an existing script project), or what happens after deployment. With sibling tools like 'list_script_deployments' and 'execute_script_function', there's no indication of how this fits into a workflow or when it's appropriate.

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

create_sheetC

Create a new sheet in an existing spreadsheet

ParametersJSON Schema

Name	Required	Description
`spreadsheet_id`	Yes	The ID of the spreadsheet
`title`	Yes	Title for the new sheet
`row_count`	No	Number of rows (default: 1000)
`column_count`	No	Number of columns (default: 26)

TDQS

C2.9/5.0

Behavior2/5

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 states the tool creates something, implying a mutation, but doesn't cover permissions, error conditions, rate limits, or what happens if a sheet with the same title exists. This is inadequate for a mutation tool without annotations.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error handling, and output format, leaving significant gaps in understanding how to use the tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying the tool uses a spreadsheet ID and title, which is already clear from the schema. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('Create a new sheet') and the resource ('in an existing spreadsheet'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'copy_sheet' or 'create_spreadsheet', which would require more specific language about what makes this tool unique.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing spreadsheet), exclusions, or comparisons to sibling tools like 'copy_sheet' or 'create_spreadsheet', leaving the agent to infer usage context.

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

create_spreadsheetB

Create a new Google Spreadsheet with optional sheets

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title of the new spreadsheet
`sheets`	No	Optional array of sheets to create

TDQS

B3.1/5.0

Behavior2/5

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 states the tool creates a new spreadsheet, implying a write/mutation operation, but doesn't cover permissions needed, rate limits, whether the operation is idempotent, what happens on failure, or the format of the response. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose ('Create a new Google Spreadsheet') and adds a useful detail ('with optional sheets'). There is no wasted verbiage, and it's appropriately sized for the tool's complexity.

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

Completeness3/5

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

Given the tool's moderate complexity (creating a resource with optional nested sheets), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output. It's complete enough to understand what the tool does at a high level but insufficient for robust agent operation without additional inference.

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

Parameters3/5

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

The schema description coverage is 100%, so the schema fully documents both parameters ('title' and 'sheets'). The description adds no additional meaning beyond what's in the schema—it mentions 'optional sheets' but doesn't explain their purpose or structure. This meets the baseline of 3 when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Create a new Google Spreadsheet') and resource ('Google Spreadsheet'), and mentions the optional feature ('with optional sheets'). It distinguishes from siblings like 'create_sheet' (which creates individual sheets within an existing spreadsheet) by focusing on creating an entire spreadsheet. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when not to use it, or compare it to related tools like 'copy_sheet' or 'create_sheet'. The agent must infer usage from the tool name and schema alone.

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

delete_sheetC

Delete a sheet from a spreadsheet

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes	The ID of the spreadsheet
`sheet_id`	Yes	The ID of the sheet to delete

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs a deletion, implying a destructive mutation, but lacks details on permissions needed, whether the action is reversible, or what happens upon success/failure. This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.

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

Completeness2/5

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

Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It should address behavioral aspects like side effects, error conditions, or return values to help an agent use it safely and effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters ('spreadsheet_id' and 'sheet_id'). The description implies these are needed but adds no meaning beyond what the schema provides, such as how to obtain these IDs or their format, meeting the baseline for high coverage.

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

Purpose4/5

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

The description clearly states the action ('Delete') and target resource ('a sheet from a spreadsheet'), making the purpose immediately understandable. It doesn't distinguish this from sibling tools like 'clear_values' or 'update_sheet_properties', which might also affect sheets, so it lacks sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a spreadsheet and sheet ID, or compare it to related tools like 'clear_values' for removing content without deleting the sheet itself.

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

execute_script_batchC

Execute multiple Apps Script functions in batch

ParametersJSON Schema

Name	Required	Description	Default
`calls`	Yes	Array of function calls

TDQS

C2.7/5.0

Behavior1/5

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 provides minimal information. It doesn't mention whether this is a read or write operation, what permissions are required, whether there are rate limits or quotas, what happens on partial failures, or what the typical response looks like. For a batch execution tool with zero annotation coverage, this is a significant gap.

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

Conciseness5/5

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

The description is extremely concise at just 6 words, with zero wasted language. Every word earns its place, and the core purpose is communicated immediately without unnecessary elaboration.

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

Completeness2/5

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

For a batch execution tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens during execution (synchronous/asynchronous), what the return values might be, error handling for partial failures, or any behavioral characteristics. The agent would need to guess about many important operational aspects.

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

Parameters3/5

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

The schema description coverage is 100%, with the single parameter 'calls' well-documented in the schema as 'Array of function calls' with detailed nested properties. The description adds no additional parameter semantics beyond what's already in the schema, so the baseline score of 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Execute multiple Apps Script functions') and resource ('in batch'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'execute_script_function' - both involve executing Apps Script functions, with the key difference being batch vs single execution.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch execution is preferable to single function execution (vs 'execute_script_function'), nor does it provide any context about prerequisites, limitations, or appropriate use cases for batch processing.

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

execute_script_functionC

Execute a function in a Google Apps Script project

ParametersJSON Schema

Name	Required	Description
`function_name`	Yes	Name of the Apps Script function to execute
`parameters`	No	Parameters to pass to the function
`dev_mode`	No	Whether to use development mode (default: false)

TDQS

C2.9/5.0

Behavior2/5

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 states the tool executes a function but lacks critical details: it doesn't mention authentication requirements, potential side effects (e.g., whether it modifies data or triggers external actions), error handling, or rate limits. This is inadequate for a tool that likely involves code execution with significant implications.

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

Conciseness5/5

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

The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the complexity of executing script functions (which can have wide-ranging effects), lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like safety, permissions, or result formats, leaving significant gaps for an agent to infer or risk incorrect usage.

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

Parameters3/5

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

The input schema has 100% description coverage, so parameters are well-documented in the schema itself. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain parameter formats, provide examples, or clarify 'dev_mode' implications). This meets the baseline for high schema coverage but doesn't enhance understanding.

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

Purpose4/5

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

The description clearly states the action ('Execute') and target ('a function in a Google Apps Script project'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'execute_script_batch', which appears to handle batch execution of scripts, leaving some ambiguity about when to choose one over the other.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a script ID or deployment setup), compare it to 'execute_script_batch', or specify scenarios where this tool is appropriate (e.g., single function calls vs. batch operations).

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

find_and_replaceC

Find and replace text in a range or entire sheet

ParametersJSON Schema

Name	Required	Description
`spreadsheet_id`	Yes	The ID of the spreadsheet
`find`	Yes	Text to find
`replacement`	Yes	Text to replace with
`range`	No	Optional A1 range to search in
`match_case`	No	Whether to match case (default: false)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the action but doesn't describe important behavioral aspects: whether this is a destructive operation (likely yes, but not stated), what permissions are required, whether it affects formulas or formatting, what happens if no matches are found, or what the response looks like. This leaves significant gaps 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.

Conciseness5/5

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

The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's front-loaded with the essential action and scope, making it easy for an agent to quickly understand what the tool does.

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

Completeness2/5

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

For a mutation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address behavioral implications, error conditions, or what the tool returns. Given the complexity of modifying spreadsheet data and the lack of structured metadata, the description should provide more complete context about how this operation works.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter interactions, edge cases, or provide examples. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('find and replace text') and resource ('in a range or entire sheet'), which is specific and unambiguous. However, it doesn't explicitly distinguish this tool from siblings like 'update_values' or 'batch_update_values', which might also modify spreadsheet content, so it doesn't achieve full sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'update_values' and 'batch_update_values' that could potentially serve similar purposes, there's no indication of when this specific find-and-replace functionality is preferred over other update methods.

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

get_auth_urlB

Get OAuth URL for authentication (for initial setup)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool retrieves an OAuth URL but doesn't disclose behavioral traits such as whether this triggers user interaction, requires specific permissions, involves rate limits, or what the expected output format is. For an authentication-related tool with zero annotation coverage, this is a significant gap.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose and context without any wasted words. It is front-loaded and appropriately sized for its simplicity.

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

Completeness3/5

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects like output format or authentication flow, which are important for an OAuth tool. With no output schema, the description should ideally explain what the URL is used for or next steps.

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

Parameters4/5

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

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it appropriately doesn't mention any, aligning with the schema. A baseline of 4 is applied for zero-parameter tools.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('OAuth URL'), and specifies the context ('for authentication, for initial setup'). It doesn't differentiate from siblings, but none of the listed sibling tools appear to handle authentication URLs, making differentiation less critical.

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

Usage Guidelines3/5

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

The description implies usage context ('for initial setup'), suggesting this tool is used during authentication initialization. However, it doesn't provide explicit guidance on when to use it versus alternatives (e.g., other auth methods) or any prerequisites, leaving some ambiguity.

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

get_script_metadataB

Get metadata about an Apps Script project

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't reveal any behavioral traits such as permissions required, rate limits, whether it's idempotent, or what the response format might be. This is a significant gap for a tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what metadata is returned, potential errors, or usage constraints. For a tool with no structured behavioral data, this minimal description leaves too many gaps for effective agent use.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, which is efficient, but it could have hinted at implicit inputs like context or authentication. Baseline is 4 for zero parameters.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'metadata about an Apps Script project', making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_spreadsheet_metadata' or 'get_server_status', which follow a similar pattern but target different resources.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the tool name alone without any explicit direction.

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

get_server_statusB

Get current server status including authentication and rate limits

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It mentions the tool retrieves 'current server status including authentication and rate limits', which implies it's a read-only operation that provides system information. However, it doesn't disclose whether this requires authentication, has rate limits itself, or what format the status information is returned in.

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

Conciseness5/5

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

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a zero-parameter status-checking tool and front-loads the essential information.

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

Completeness3/5

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

For a simple status-checking tool with no parameters and no output schema, the description is adequate but minimal. It specifies what information is included (authentication and rate limits) but doesn't explain the return format or how to interpret the results. Given the lack of annotations and output schema, more detail about the response structure would be helpful.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing parameters that don't exist, maintaining focus on what the tool does rather than what it accepts.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'server status', specifying it includes 'authentication and rate limits'. It's specific about what information is retrieved, though it doesn't explicitly distinguish this tool from its many siblings (none of which appear to be status-checking tools).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, timing considerations, or relationship to other tools. With 24 sibling tools, this is a significant gap in helping the agent understand the tool's role in the broader context.

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

get_spreadsheet_metadataC

Get metadata for a Google Spreadsheet including sheet info

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes	The ID of the spreadsheet (from URL)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the tool retrieves metadata, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error handling, or what specific metadata is returned (beyond 'sheet info'). This is inadequate for a tool with no annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Get metadata for a Google Spreadsheet') and adds a clarifying detail ('including sheet info'). 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.

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It lacks details on return values (what metadata beyond 'sheet info'), error conditions, or operational context (e.g., permissions needed). For a tool with zero structured coverage, this minimal description fails to provide sufficient context for effective use.

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

Parameters3/5

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

Schema description coverage is 100%, with the single parameter 'spreadsheet_id' documented in the schema. The description adds no parameter-specific information beyond what the schema provides (e.g., no examples or clarifications on ID format). Baseline 3 is appropriate as the schema handles parameter documentation.

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

Purpose4/5

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

The description clearly states the action ('Get metadata') and resource ('Google Spreadsheet'), specifying it includes 'sheet info'. It distinguishes from obvious siblings like 'get_values' or 'get_values_formatted' by focusing on metadata rather than cell data. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_script_metadata' might be ambiguous).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a spreadsheet ID), exclusions, or comparisons to siblings like 'get_values' (for data) or 'get_script_metadata' (for scripts). Usage is implied only by the tool name and description.

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

get_valuesC

Get values from a range in a spreadsheet (raw values)

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes	The ID of the spreadsheet
`range`	Yes	A1 notation range (e.g., "Sheet1!A1:B10")

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states it retrieves raw values. It lacks details on permissions needed, rate limits, error handling, or whether it's read-only (implied but not explicit). More behavioral context is needed for a mutation-heavy sibling set.

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

Conciseness5/5

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and includes a clarifying detail about raw values, 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.

Completeness2/5

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

Given no annotations, no output schema, and a context with many mutation siblings, the description is incomplete. It doesn't address return format, error cases, or safety considerations, leaving gaps for an AI agent to infer behavior in a complex spreadsheet environment.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond implying raw values are returned, which doesn't enhance parameter understanding beyond the schema's details.

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

Purpose4/5

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

The description clearly states the action ('Get values') and resource ('from a range in a spreadsheet'), specifying it returns raw values. It distinguishes from 'get_values_formatted' by noting the raw nature, but doesn't explicitly contrast with all sibling tools like 'clear_values' or 'update_values'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention when to choose 'get_values' over 'get_values_formatted' or other data retrieval methods, nor does it specify prerequisites or exclusions for usage.

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

get_values_formattedC

Get values from a range with formatting applied

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes	The ID of the spreadsheet
`range`	Yes	A1 notation range

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions formatting is applied, which hints at read-only behavior, but doesn't disclose critical details like authentication needs, rate limits, error conditions, or what 'formatting applied' entails (e.g., cell formatting vs. data transformation). For a tool with no annotation coverage, this is insufficient.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and avoids unnecessary elaboration, making it easy to parse quickly.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'formatting applied' means in practice, the return format, or any behavioral traits. For a tool that presumably returns formatted data, this leaves significant gaps for an agent to understand its operation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond implying the range parameter affects formatted output, but doesn't specify format details or constraints. Baseline 3 is appropriate as the schema handles parameter documentation.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('values from a range'), specifying that formatting is applied. It distinguishes from sibling 'get_values' by mentioning formatting, but doesn't fully differentiate from other data retrieval tools like 'get_spreadsheet_metadata' in terms of scope.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives is provided. The description doesn't mention when to choose this over 'get_values' (which presumably returns unformatted values) or other data access tools, nor does it specify prerequisites or exclusions.

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

list_script_deploymentsB

List all deployments of an Apps Script project

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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 states the action ('List all deployments') but doesn't add any context about what 'all deployments' entails (e.g., pagination, filtering, or return format), permissions required, rate limits, or error conditions, which are critical for a tool that likely interacts with a deployment system.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and appropriately sized, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the complexity of listing deployments (which may involve permissions, pagination, or filtering), the description is incomplete. With no annotations, no output schema, and minimal behavioral context, it fails to provide enough information for an agent to use the tool effectively in real-world scenarios, such as understanding the response structure or handling edge cases.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. A baseline of 4 is appropriate as the description doesn't need to compensate for missing param info, though it could hint at implicit parameters (e.g., script ID) for a higher score.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('deployments of an Apps Script project'), making the purpose specific and understandable. However, it doesn't distinguish this tool from potential siblings like 'get_script_metadata' or 'execute_script_function', which could also relate to Apps Script projects, so it doesn't reach the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a script ID), exclusions, or comparisons to other tools like 'get_script_metadata' or 'create_script_deployment', leaving the agent with no contextual usage information.

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

reset_circuit_breakerB

Reset the circuit breaker after it has opened

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the action ('reset') but lacks details on permissions, side effects (e.g., if it restarts systems), rate limits, or response behavior. This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and context, making it easy to parse quickly.

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

Completeness2/5

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

Given the tool's mutation nature (implied by 'reset'), lack of annotations, and no output schema, the description is incomplete. It fails to explain behavioral traits, return values, or error conditions, leaving significant gaps for an agent to use it correctly.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, earning a baseline 4.

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

Purpose4/5

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

The description clearly states the action ('reset') and the target resource ('circuit breaker'), making the purpose understandable. However, it doesn't differentiate from sibling tools (none are circuit-breaker related), so it doesn't achieve full distinction.

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

Usage Guidelines2/5

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

The description provides minimal guidance ('after it has opened'), implying a precondition but not specifying when to use this tool versus alternatives or what 'opened' means in context. No explicit when-not or sibling comparisons are given.

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

set_script_idB

Set the Apps Script project ID for subsequent operations

ParametersJSON Schema

Name	Required	Description	Default
`script_id`	Yes	The script ID from the Apps Script URL

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It states the tool sets an ID for future use, but doesn't disclose behavioral traits like whether it's idempotent, if it persists across sessions, error handling, or permissions required. This leaves gaps in understanding how the tool behaves beyond its basic function.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to understand at a glance.

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

Completeness3/5

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

Given the tool's low complexity (one parameter, no output schema) and lack of annotations, the description is minimally adequate. It covers the basic purpose but misses details like behavioral context or usage scenarios, which would enhance completeness for an agent's decision-making.

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

Parameters3/5

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

Schema description coverage is 100%, with the single parameter 'script_id' well-documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or sourcing details, so it meets the baseline for high coverage without extra value.

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

Purpose4/5

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

The description clearly states the action ('Set') and the resource ('Apps Script project ID'), specifying it's for subsequent operations. However, it doesn't differentiate from siblings like 'create_script_deployment' or 'get_script_metadata', which are related but distinct operations.

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

Usage Guidelines2/5

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

The description implies usage before other operations ('for subsequent operations'), but provides no explicit guidance on when to use this tool versus alternatives or prerequisites. It lacks details on context, such as whether it's required before executing scripts or optional for certain tasks.

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

sort_rangeC

Sort a range by one or more columns

ParametersJSON Schema

Name	Required	Description
`spreadsheet_id`	Yes	The ID of the spreadsheet
`range`	Yes	A1 notation range to sort
`sort_specs`	Yes	Sort specifications

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While 'sort' implies a mutation operation, the description doesn't specify whether this requires write permissions, whether the operation is reversible, what happens to data outside the sorted range, or any rate limits/constraints. For a mutation tool with zero annotation coverage, this represents significant gaps in behavioral context.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward operation and front-loads the essential information (sorting a range). Every word earns its place in conveying the core functionality.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like permissions needed, whether the operation is destructive to existing data, what the return value contains, or error conditions. Given the complexity of modifying spreadsheet data and the lack of structured metadata, the description should provide more operational context.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description mentions 'by one or more columns' which aligns with the 'sort_specs' array parameter, but adds no additional semantic context beyond what the schema provides about how sorting actually works or the implications of different sort specifications.

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

Purpose4/5

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

The description clearly states the action ('sort') and target ('a range by one or more columns'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'batch_update_values' or 'update_values' that might also modify spreadsheet content, leaving room for ambiguity about when sorting is the appropriate operation versus other data manipulation methods.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that modify spreadsheet data (e.g., 'update_values', 'batch_update_values', 'find_and_replace'), there's no indication of whether sorting is preferred for reorganization versus other update operations, or any prerequisites for using this tool.

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

update_cells_formatC

Apply formatting to a range of cells

ParametersJSON Schema

Name	Required	Description
`spreadsheet_id`	Yes	The ID of the spreadsheet
`range`	Yes	A1 notation range
`format`	Yes	Format specification

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Apply formatting' implies a mutation operation, but the description doesn't mention permissions required, whether formatting overwrites existing formatting, if changes are reversible, rate limits, or what happens on success/failure. For a write operation with zero annotation coverage, this leaves significant behavioral gaps.

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

Conciseness5/5

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

The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point with no unnecessary elaboration.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after formatting is applied, what the response looks like, error conditions, or how this tool relates to other spreadsheet operations. Given the complexity implied by the nested format object and the write nature of the operation, more context is needed for effective use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain format object structure, range notation details, or provide examples. This meets the baseline for high schema coverage but doesn't enhance understanding.

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

Purpose4/5

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

The description clearly states the action ('Apply formatting') and target ('to a range of cells'), which is specific and unambiguous. It doesn't explicitly differentiate from siblings like 'update_values' or 'get_values_formatted', but the verb 'apply formatting' strongly implies a write operation focused on visual presentation rather than data content.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'update_values' (which might handle data updates), 'clear_values', and 'get_values_formatted', there's no indication of when formatting changes should use this specific tool versus other update mechanisms. No prerequisites, constraints, or alternatives are mentioned.

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

update_sheet_propertiesC

Update properties of a sheet (title, grid properties)

ParametersJSON Schema

Name	Required	Description
`spreadsheet_id`	Yes	The ID of the spreadsheet
`sheet_id`	Yes	The ID of the sheet to update
`properties`	Yes	Properties to update

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update' implies a mutation, but the description doesn't state whether this requires specific permissions, whether changes are reversible, what happens to existing properties not mentioned, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap—it lacks critical context like error conditions or 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.

Conciseness5/5

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

The description is a single, efficient sentence with zero waste—it directly states the tool's purpose and scope. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly without unnecessary elaboration.

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

Completeness2/5

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

Given the complexity (mutation tool with nested parameters) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, idempotency, or response format, leaving gaps that could hinder correct tool invocation. For a tool that modifies resources, more context is needed to ensure safe and effective use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters and their nested structures. The description adds minimal value by listing 'title' and 'grid properties' as updatable, which aligns with the schema but doesn't provide additional semantics (e.g., format constraints or examples). Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Update') and resource ('properties of a sheet'), and specifies the types of properties that can be updated ('title, grid properties'). It distinguishes this tool from siblings like 'update_cells_format' or 'update_values' by focusing on sheet-level properties rather than cell content or formatting. However, it doesn't explicitly mention what distinguishes it from 'create_sheet' or 'delete_sheet' beyond the update action.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a spreadsheet and sheet ID), when this tool is appropriate compared to 'create_sheet' or 'delete_sheet', or any constraints on usage. The agent must infer usage from the tool name and parameters alone.

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

update_valuesC

Update values in a range of cells

ParametersJSON Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes	The ID of the spreadsheet
`range`	Yes	A1 notation range to update
`values`	Yes	2D array of values to write
`input_option`	No	How to interpret input (RAW or USER_ENTERED)	USER_ENTERED

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states this is an update operation but does not disclose behavioral traits such as permissions required, whether it overwrites or merges existing data, error handling, or rate limits. This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavior, error cases, or return values, leaving significant gaps in understanding how to use the tool effectively in context.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying cell range updates, which is already covered by the schema. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('Update') and target ('values in a range of cells'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'batch_update_values' or 'append_values', which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'batch_update_values', 'append_values', and 'clear_values' available, there is no indication of context, prerequisites, or exclusions for this tool's usage.

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

Tool Schema Changelog

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

26 tool updatesv1.0.0Mar 14, 2026
- First observedadd_data_validation
- First observedappend_values
- First observedbatch_update_values
- First observedclear_values
- First observedcopy_sheet
- First observedcreate_protected_range
- First observedcreate_script_deployment
- First observedcreate_sheet
- First observedcreate_spreadsheet
- First observeddelete_sheet
- First observedexecute_script_batch
- First observedexecute_script_function
- First observedfind_and_replace
- First observedget_auth_url
- First observedget_script_metadata
- First observedget_server_status
- First observedget_spreadsheet_metadata
- First observedget_values
- First observedget_values_formatted
- First observedlist_script_deployments
- First observedreset_circuit_breaker
- First observedset_script_id
- First observedsort_range
- First observedupdate_cells_format
- First observedupdate_sheet_properties
- First observedupdate_values

Install Server

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

TDQS

B3.3/5.0

Disambiguation4/5

Most tools have distinct purposes, but some overlap exists. For example, 'update_values' and 'batch_update_values' could be confused, as batch updates are a subset of updates. Similarly, 'get_values' and 'get_values_formatted' are closely related, though the formatted version adds formatting details. Overall, descriptions help clarify differences, but minor ambiguities remain.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern throughout, such as 'add_data_validation', 'append_values', and 'create_spreadsheet'. There are no deviations in style or convention, making the naming predictable and easy to understand across all 26 tools.

Tool Count3/5

With 26 tools, the count is borderline high for a single server, potentially making it heavy for agents to navigate. However, given the advanced scope covering Google Sheets and Apps Script operations, it's reasonable but may feel overwhelming compared to more focused servers.

Completeness5/5

The tool set provides comprehensive coverage for Google Sheets and Apps Script management, including CRUD operations for spreadsheets, sheets, and data, as well as advanced features like scripting, formatting, and authentication. No obvious gaps are present, supporting full lifecycle workflows in this domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
Google Compute Engine A
com.googleapis.compute
The Google Compute Engine MCP server is a fully-managed Model Context Protocol server that provides tools to manage Google Compute Engine resources through AI agents. It enables capabilities including instance management (creating, starting, stopping, resetting, listing), disk management, handling instance templates and group managers, viewing machine and accelerator types, managing images, and accessing reservation and commitment information. The server operates as a zero-deployment, enterprise-grade endpoint at https://compute.googleapis.com/mcp with built-in IAM-based security.
Cloud Platforms Virtualization Agent Orchestration
292
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

Google Sheets Analytics MCP
Databases App Automation Search
talknerdytome-labs
A
license
Not graded
quality
D
maintenance
This MCP server enables AI assistants to automatically sync Google Sheets data to a local database and perform natural language queries and analysis on spreadsheet data.
Updated a year ago (2025-08-31 03:03 UTC)
19
4
MIT
Google Sheets MCP
Workplace & Productivity App Automation Autonomous Agents
Jsgordon420365
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI agents to read, create, and modify Google Spreadsheets through actions like editing cells and managing sheets. It features a specialized handoff protocol to synchronize tasks and state between different LLMs using a shared spreadsheet log.
Updated 7 months ago (2026-02-16 18:41 UTC)
178
MIT
gworkspace-mcp
Workplace & Productivity App Automation Developer Tools
LeooNic
A
license
B
quality
D
maintenance
An MCP server for automating Google Workspace applications including Sheets, Apps Script, Drive, Docs, and Gmail. It enables users to manipulate spreadsheets, edit scripts, manage files, and send emails directly from conversational AI interfaces.
Updated 5 months ago (2026-04-14 00:07 UTC)
31
MIT
Google Workspace MCP Server
Workplace & Productivity Email Calendar Management
sputnicyoji
A
license
Not graded
quality
D
maintenance
A comprehensive MCP server integrating Google Docs, Sheets, Drive, Gmail, Calendar, and Apps Script APIs, featuring unique Apps Script support for AI-driven automation.
Updated 8 months ago (2026-01-08 16:57 UTC)
11
8
MIT

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/devfinprojects/GAS_MCPSERVER_ADAVANCED'

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