google-workspace-mcp-advanced

delete_deployment

Delete an Apps Script deployment with an optional dry run to preview changes before mutation.

Instructions

Delete an Apps Script deployment.

Args: user_google_email: The user's Google email address. Required. script_id: The Apps Script project ID. deployment_id: The deployment ID to delete. dry_run: Preview deletion without mutation. Defaults to True.

Returns: str: Confirmation of preview or deletion.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "user_google_email": "<user_google_email>",
      "script_id": "<script_id>",
      "deployment_id": "<deployment_id>"
    },
    "name": "delete_deployment"
  }
}

Input Schema

Name	Required	Description	Default
`user_google_email`	Yes
`script_id`	Yes
`deployment_id`	Yes
`dry_run`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.10Jun 2, 2026

TDQS

A3.8/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 the full burden. It states that the tool deletes a deployment and that dry_run previews without mutation (defaults to True). However, it does not disclose side effects, irreversibility when dry_run is False, or required permissions. The description is adequate but lacks depth.

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

Conciseness5/5

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

The description is concise: one sentence for purpose, then a bullet-like list of arguments. No extraneous information. Front-loaded with the action.

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 that the tool is simple (deletion with a dry run option) and an output schema exists (returning a string), the description covers the essential information. However, it could mention that deletion is irreversible when dry_run is False or that specific permissions are required.

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?

Schema coverage is 0% (no parameter descriptions in the schema), but the description compensates by listing each parameter with a brief explanation: user_google_email (Required, user's email), script_id (project ID), deployment_id (ID to delete), dry_run (preview without mutation, defaults True). This adds meaningful context beyond type and required fields.

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

Purpose5/5

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

The description clearly states 'Delete an Apps Script deployment,' which is a specific verb and resource. It distinguishes itself from siblings like `create_deployment` and `update_deployment` by specifying the delete 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?

No explicit guidance on when to use this tool versus alternatives. While the dry_run parameter hints at preview behavior, there is no mention of prerequisites, when to use delete vs create/update, or when not to use this tool.

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

Deploy Server