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

Manage Document Comment

manage_document_comment

Create, reply to, or resolve comments on Google Docs. Provide the document ID, action, and comment content to manage discussions.

Instructions

Manage comments on a Google Document.

Actions:

create: Create a new document-level comment. Requires comment_content. Note: The Drive API cannot anchor comments to specific text; only the Google Docs UI can do that.
reply: Reply to a comment. Requires comment_id and comment_content.
resolve: Resolve a comment. Requires comment_id.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`action`	Yes
`comment_id`	No
`document_id`	Yes
`comment_content`	No
`user_google_email`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.28.0Sep 24, 2026
- removedInput schema / properties / comment_content / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / comment_content / type
```
Added value: +"string"
```
- removedInput schema / properties / comment_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / comment_id / type
```
Added value: +"string"
```
Addedv1.0.1Jul 31, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations convey that this is mutating and non-idempotent, but the description adds a key behavioral constraint: the Drive API cannot anchor comments to text, only the Docs UI can. This prevents the agent from assuming text anchoring support. No contradiction with 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?

Three compact bullets plus one necessary note about anchoring. Every sentence earns its place, and the format makes the action-parameter mapping immediately scannable.

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?

All three operations are described with prerequisites, and the open-world caveat is addressed. An output schema exists, so omitting return values is fine. The only gap is not mentioning that document_id and user_google_email apply to every action, but that is inferable from the schema and required fields.

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 0%, so the description must explain parameter roles. It does nicely map action-specific parameters (comment_content, comment_id), but gives no guidance on user_google_email or document_id, which are also required. Names make them self-explanatory, but the description doesn't compensate fully for the zero 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 specific verb and resource: 'Manage comments on a Google Document,' then enumerates three concrete actions (create, reply, resolve), distinguishing it from sibling tools like list_document_comments. Each action is named with its specific purpose.

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 for when to use this tool and what each action requiresaislado. It doesn't explicitly contrast with list_document_comments or spreadsheet/presentation comment tools, but the 'Google Document' scope and action list make the intended use case unambiguous.

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

Deploy Server