Google Workspace MCP Server - Control Gmail, Calendar, Docs, Sheets, Slides, Chat, Forms & Drive

Manage Script Trigger

manage_script_trigger

Destructive

List or delete installable triggers on a Google Apps Script project. Use this to inspect or remove triggers without opening the editor.

Instructions

List or delete the current user's installable triggers on a script project.

The Apps Script REST API has no triggers resource, so in dev_mode both actions provision (or refresh) a small helper file and run it via the Execution API - the only way to inspect or change trigger state without opening the editor. Neither action is read-only: the helper file may be written into the project on first use. To create a trigger, use generate_trigger_code to produce the setup code, add it with manage_script_content, then run it with run_script_function.

Input Schema

TableJSON Schema

Name	Required	Description
`action`	Yes	One of "list", "delete".
`dev_mode`	No	Run against the latest saved code (default; project owner only) vs. the deployed version. False requires the helper to already exist in the deployed version.
`script_id`	Yes	The script project ID.
`trigger_id`	No	Unique ID of a specific trigger to delete (delete only).
`deployment_id`	No	Optional API Executable deployment ID. When omitted, the highest versioned API Executable deployment is used.
`handler_function`	No	Delete all triggers calling this function name (delete only).
`user_google_email`	Yes	User's email address

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.28.0Sep 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses that both actions are not read-only and may write a helper file into the project, which goes beyond the annotations (destructiveHint=true) by specifying the exact side effect. It also explains the mechanism (helper file via Execution API), giving agents critical awareness of state changes even for a 'list' action.

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

Conciseness4/5

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

The description is front-loaded with the core purpose and then provides necessary context about the mechanism and creation alternative. Each sentence serves a purpose, though the middle paragraph could be tightened slightly; still, it's well-structured and not redundant.

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

Completeness4/5

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

Given the tool's complexity (7 parameters, output schema, annotations), the description covers the key behavioral quirks (helper file, non-read-only nature) and routes creation appropriately. It doesn't explicitly detail return values, but an output schema exists, and the schema covers parameter requirements. Slightly more could be said about error cases or deployment specifics, but overall it's complete for an agent to call correctly.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already has a clear description (e.g., action, dev_mode, trigger_id). The description adds general context about dev_mode behavior but doesn't add per-parameter meaning beyond what the schema provides. Baseline 3 is appropriate for high schema coverage.

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

Purpose5/5

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

The description states a clear verb+resource: 'List or delete the current user's installable triggers on a script project.' It distinguishes from siblings by explicitly naming the creation path via generate_trigger_code, manage_script_content, and run_script_function, so an agent can tell this tool handles list/delete only.

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

Usage Guidelines5/5

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

It explicitly directs when not to use this tool: 'To create a trigger, use generate_trigger_code ... then run it with run_script_function.' This provides clear alternative routing and explains the dev_mode provisioning mechanism, leaving no ambiguity about when to invoke this tool versus its siblings.

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

Deploy Server