Skip to main content
Glama
taylorwilsdon

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

Manage Spreadsheet Comment

manage_spreadsheet_comment

Create, reply to, or resolve comments on Google Sheets cells. Use this tool to manage spreadsheet comment threads through simple actions.

Instructions

Manage comments on a Google Spreadsheet.

Actions:

  • create: Create a new comment. Requires comment_content. Note: The Drive API cannot anchor comments to arbitrary text; Sheets comments are cell-scoped via the API.

  • reply: Reply to a comment. Requires comment_id and comment_content.

  • resolve: Resolve a comment. Requires comment_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
comment_idNo
spreadsheet_idYes
comment_contentNo
user_google_emailYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.28.0
    • 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"
  2. Addedv1.0.1

TDQS

A3.8/5.0
Behavior3/5

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

The description adds a meaningful behavioral note: the Drive API cannot anchor comments to arbitrary text and Sheets comments are cell-scoped. Annotations already signal mutation (readOnlyHint false), but the description does not cover permissions, reversibility of resolve, or other side effects, so transparency is adequate but not rich.

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 compact, scannable, and front-loaded with purpose, followed by a clear action list and a relevant API limitation. Each sentence adds value without unnecessary repetition.

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?

The description covers all three actions with their required parameters and includes a useful API constraint, while the output schema handles return-value expectations. It does not explicitly address auth/permissions or parameter formats, but the tool is reasonably complete for correct invocation.

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?

With 0% schema description coverage, the description is the main source of parameter meaning and does explain action-specific dependencies (comment_content for create/reply, comment_id for reply/resolve). It leaves user_google_email and spreadsheet_id implicit, so it only partially compensates for the schema gap.

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 identifies the resource (comments on a Google Spreadsheet) and lists specific actions (create, reply, resolve), making the tool's purpose concrete. This also distinguishes it from sibling comment tools for documents and presentations.

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

Usage Guidelines3/5

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

The description gives action-specific requirements, such as needing comment_content for create and comment_id for reply/resolve, and adds an API limitation note. However, it does not explicitly say when to prefer this tool over siblings like list_spreadsheet_comments or manage_document_comment, so usage guidance is mostly 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