gdocs-mcp

Accept/reject one or more suggestions

apply_suggestions

Accept or reject pending Google Docs suggestions in one update, resolving each individually. It verifies the document title and each suggestion's context before making any changes.

Instructions

Accept or reject pending suggestions (from list_suggestions) in one update. Each one is resolved on its own, exactly as clicking the check or the cross in Docs: accept keeps the proposed change, reject restores the original. Two suggestions that touch each other (by different people) are decided one at a time, and the text comes out as Docs makes it; to decide them together, pass both. A style-only suggestion resolves like any other. expectTitle is checked against the live document first (status "wrong_doc" on a mismatch, e.g. an id from a different, similarly-titled document), and each expectContext is checked against the live suggestion (status "error" on a mismatch or an id that is gone); nothing is changed unless all match. Pass the title and each suggestion’s context from list_suggestions, verbatim.

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": {
      "path": "<path>",
      "expectTitle": "<expectTitle>",
      "resolutions": "<resolutions>"
    },
    "name": "apply_suggestions"
  }
}

Input Schema

Name	Required	Description
`page`	No	which header/footer, when a doc defines more than one (default-page, first-page, even-page). Omit to use whichever exists.
`path`	Yes	The doc or tab: a Drive id or URL, /folder/doc, or /folder/doc/tab (nested: /folder/doc/tab/child). A doc with one tab needs no tab step; a doc with several is refused until one is named, and the refusal lists every tab path.
`account`	No	Google account email to use. Defaults to GDOCS_DEFAULT_ACCOUNT, or the sole account.
`segment`	No	which content tree to target: body (default), or the page header/footer. Header/footer content is invisible to a body read — a letterhead logo lives there.
`expectTitle`	Yes	the document’s title, from list_suggestions; checked before anything is changed
`resolutions`	Yes	one entry per suggestion to resolve

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv1.0.0Oct 31, 2026

removedInput schema / properties / documentId

Removed value: -{
-  "description": "Google Doc id",
-  "type": "string"
-}

removedInput schema / properties / documentTitle

Removed value: -{
-  "description": "The document's title, from list_suggestions. Shown for confirmation only.",
-  "type": "string"
-}

addedInput schema / properties / expectTitle

Added value: +{
+  "description": "the document’s title, from list_suggestions; checked before anything is changed",
+  "type": "string"
+}

addedInput schema / properties / path

Added value: +{
+  "description": "The doc or tab: a Drive id or URL, /folder/doc, or /folder/doc/tab (nested: /folder/doc/tab/child). A doc with one tab needs no tab step; a doc with several is refused until one is named, and the refusal lists every tab path.",
+  "type": "string"
+}

addedInput schema / properties / resolutions / items / properties / expectContext

Added value: +{
+  "description": "the suggestion’s `context` from list_suggestions, verbatim",
+  "type": "string"
+}

removedInput schema / properties / resolutions / items / properties / expectedChange

Removed value: -{
-  "description": "the suggestion's `preview` from list_suggestions",
-  "type": "string"
-}

changedInput schema / properties / resolutions / items / required

Previous value: -[
-  "suggestionId",
-  "decision",
-  "expectedChange"
-]New value: +[
+  "suggestionId",
+  "decision",
+  "expectContext"
+]

removedInput schema / properties / tab

Removed value: -{
-  "description": "Target a specific tab by tabId or title (from list_tabs). Defaults to the first tab.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "documentId",
-  "documentTitle",
-  "resolutions"
-]New value: +[
+  "path",
+  "expectTitle",
+  "resolutions"
+]

Changed2 schema fields changedv0.5.0Aug 17, 2026

addedInput schema / properties / page

Added value: +{
+  "description": "which header/footer, when a doc defines more than one (default-page, first-page, even-page). Omit to use whichever exists.",
+  "enum": [
+    "default",
+    "first",
+    "even"
+  ],
+  "type": "string"
+}

addedInput schema / properties / segment

Added value: +{
+  "description": "which content tree to target: body (default), or the page header/footer. Header/footer content is invisible to a body read — a letterhead logo lives there.",
+  "enum": [
+    "body",
+    "header",
+    "footer"
+  ],
+  "type": "string"
+}

First observedv0.1.1Aug 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it explains per-suggestion resolution, accept versus reject effects, how touching suggestions are decided, style-only suggestions, preflight title/context validation with wrong_doc and error statuses, and the all-or-nothing guarantee.

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 core action is front-loaded in the first clause, and each subsequent sentence adds distinct behavioral or validation information. There is no filler or repetition; the length is justified by the tool's complexity.

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 mutation tool with no annotations, no output schema, and a fully described input schema, the description is complete enough: it covers preconditions, atomicity, edge cases, and status behavior. Missing permission details are not material here because the schema and tool context supply account/path handling.

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%, so the schema already documents all parameters. The description reinforces expectTitle and expectContext semantics and verbatim sourcing from list_suggestions, but adds little parameter syntax or meaning beyond the structured schema, making baseline 3 appropriate.

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 pair (accept/reject), resource (pending suggestions), and scope (in one update), and explicitly ties the tool to list_suggestions. An agent can distinguish it from read/list/comment-resolution siblings without opening the schema.

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?

It clearly says to use this for pending suggestions from list_suggestions and instructs passing title and each suggestion's context verbatim. It does not explicitly name when not to use it or contrast it with alternatives such as edit_doc or resolve_comment, so it stops short of full when/when-not guidance.

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