mcp-google-workspace

Overview Schema Source Related Servers Discussions Admin

Commit Workspace Action

commit_workspace_action

DestructiveIdempotent

Execute a previously prepared Google Workspace action exactly once after the user approves its preview, using a one-time token and returning the committed result.

Instructions

Run the call prepared with prepare_workspace_action, with exactly the bound arguments, at most once; this is the step that carries out a consequential action, so call it only after the user has seen the preview and agreed. A client that can ask the user directly is still asked here. A token that is invalid, expired or another user's is rejected. Returns status 'committed' with tool and the bound tool's result, that tool's error result if it failed, or its confirmation question if it asks one.

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": {
      "commit_token": "<commit_token>"
    },
    "name": "commit_workspace_action"
  }
}

Input Schema

Name	Required	Description	Default
`commit_token`	Yes	One-time, principal-bound token from prepare_workspace_action's response; expires 10 minutes after issuance by default (MCP_CONFIRMATION_TTL_SECONDS). The bound action runs at most once: repeating a commit that already ran returns its saved result, and a confirmation question keeps the token valid for the answering call.

Output Schema

Name	Required	Description
`tool`	No
`result`	No
`status`	No	Machine-readable operation status.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv2.1.0Nov 6, 2026

removedInput schema / maxProperties
```
Removed value: -10000
```

changedInput schema / properties / commit_token / description

Previous value: -"One-time, principal-bound token from prepare_workspace_action's response; expires 5 minutes after issuance and is consumed on first use."New value: +"One-time, principal-bound token from prepare_workspace_action's response; expires 10 minutes after issuance by default (MCP_CONFIRMATION_TTL_SECONDS). The bound action runs at most once: repeating a commit that already ran returns its saved result, and a confirmation question keeps the token valid for the answering call."

removedInput schema / properties / commit_token / maxLength
```
Removed value: -1000000
```
changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +true
```

removedOutput schema / description

Removed value: -"Documented structured response returned by this MCP tool."

removedOutput schema / properties / context

Removed value: -{
-  "description": "Identifying request arguments echoed back with an error.",
-  "type": "object"
-}

removedOutput schema / properties / error

Removed value: -{
-  "description": "Error message or structured error details when the call failed.",
-  "type": [
-    "object",
-    "string"
-  ]
-}

removedOutput schema / properties / provider_status

Removed value: -{
-  "description": "HTTP status code returned by the Google API for a failed call.",
-  "type": "integer"
-}

removedOutput schema / properties / resource

Removed value: -{
-  "additionalProperties": false,
-  "description": "Stable cross-tool Workspace resource handle when applicable.",
-  "properties": {
-    "etag": {
-      "description": "Provider entity tag.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "id": {
-      "description": "Provider resource identifier.",
-      "type": "string"
-    },
-    "kind": {
-      "description": "Workspace resource kind.",
-      "type": "string"
-    },
-    "mime_type": {
-      "description": "MIME type when applicable.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "modified_at": {
-      "description": "Last modification time.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "name": {
-      "description": "Human-readable name.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "uri": {
-      "description": "Stable Workspace resource URI.",
-      "type": "string"
-    },
-    "web_url": {
-      "description": "Provider web URL.",
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "kind",
-    "id",
-    "uri"
-  ],
-  "type": "object"
-}

removedOutput schema / properties / result / description
```
Removed value: -"Response field: result."
```
removedOutput schema / properties / tool / description
```
Removed value: -"Response field: tool."
```

removedOutput schema / title

Removed value: -"Commit Workspace Action response"

Changed3 schema fields changedv0.3.10Aug 8, 2026

addedOutput schema / properties / context

Added value: +{
+  "description": "Identifying request arguments echoed back with an error.",
+  "type": "object"
+}

addedOutput schema / properties / error

Added value: +{
+  "description": "Error message or structured error details when the call failed.",
+  "type": [
+    "object",
+    "string"
+  ]
+}

addedOutput schema / properties / provider_status

Added value: +{
+  "description": "HTTP status code returned by the Google API for a failed call.",
+  "type": "integer"
+}

First observedv0.3.7Jul 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description goes well beyond them: it explains token rejection conditions (invalid, expired, another user's), the at-most-once replay behavior, and the three possible response shapes (committed with result, bound tool's error, or a confirmation question that keeps the token alive). That is substantive behavioral disclosure not recoverable from the annotation flags.

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?

Front-loaded with the action and constrained to four dense sentences, each carrying real information. The one weak spot is 'A client that can ask the user directly is still asked here', which is slightly cryptic on first read and could be phrased more plainly.

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

Completeness5/5

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

For a single-parameter, destructive, one-time commit tool this covers the prerequisites (a prepared token), the safety gate (user agreement), the failure modes (bad token), and the return variants. An output schema exists, yet the short return summary still orients the agent to the three possible outcomes.

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% and the single commit_token parameter is already fully documented, including its 10-minute TTL and at-most-once replay semantics. The description adds only supporting context (which tool mints the token, what the bound arguments are) rather than new parameter-level meaning, so the baseline 3 applies.

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?

States a specific verb+resource ('Run the call prepared with prepare_workspace_action') and immediately distinguishes itself from the sibling prepare tool by naming it as the source of the bound call. An agent can tell this is the execution step, not the preparation step, without opening any schema.

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?

Explicitly says when to call ('only after the user has seen the preview and agreed') and when not to, plus the at-most-once constraint. It even closes the loophole of a client that could ask the user out-of-band by stating it 'is still asked here', which is exactly the kind of routing rule that prevents misuse.

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

Deploy Server