Skip to main content
Glama
Sign In
Google Workspace (GWS) MCP Server

Google Workspace (GWS) MCP Server

by conorbronsdon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

drive_comments_update

DestructiveIdempotent

Change the text of an existing comment on a Google Drive file. Overwrites the previous content; only the comment's author can update it.

Instructions

Change the text of an existing comment. This overwrites the comment's content; the previous text is not retained. Only the comment's own author can update it — the API rejects the request otherwise. The resolved state can't be changed here: see drive_replies_create's action field.

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": {
      "fileId": "<fileId>",
      "commentId": "<commentId>",
      "fields": "<fields>",
      "content": "<content>"
    },
    "name": "drive_comments_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
fieldsYesFields to include in the response (required by the API for this resource, e.g. "id,content,modifiedTime")
fileIdYesThe file the comment belongs to
contentYesNew comment text
commentIdYesThe comment to update

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable behavior: the overwrite semantics ('previous text is not retained') and an authorization requirement ('Only the comment's own author can update it — the API rejects the request otherwise'). This goes beyond annotations and directly informs the agent of side effects and failure conditions.

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 four sentences, each earning its place: the core action is front-loaded, then overwrite behavior, then authorization, then a pointer to an alternative for resolved state. No fluff, well ordered.

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?

For a mutation tool with no output schema, the description covers the main behavioral requirements (overwrite, auth, resolved state exclusion). It does not describe the return value, but that is not critical given no output schema and the tool's simple nature. It is complete enough for an agent to call it 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% — every parameter has a clear description (e.g., 'content' = 'New comment text', 'fields' = required response fields). The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline of 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?

The description opens with a specific verb and resource: "Change the text of an existing comment." This clearly distinguishes it from siblings like drive_comments_create and drive_comments_delete. It also explicitly states what it does not do (resolved state), reinforcing its scope.

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

Usage Guidelines4/5

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

The description gives clear context: it's for updating an existing comment's text, and it explicitly points to drive_replies_create's action field for changing resolved state, which is a 'when not' guide. It also mentions the author-only requirement as a prerequisite, but does not explicitly contrast with other comment operations (e.g., create vs update). Still, the usage context is well implied.

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

Deploy Server

Other Tools