Skip to main content
Glama
taylorwilsdon

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

by taylorwilsdon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Modify Doc Text

modify_doc_text
Destructive

Edit Google Docs text in one call: insert or replace content and apply formatting, or target a heading section to update its body without manual index calculations.

Instructions

Modifies text in a Google Doc - can insert/replace text and/or apply formatting in a single operation.

TIP: To append text to the end of the document without calculating indices, set end_of_segment=true. This avoids index calculation errors.

HEADING MODE: Pass heading instead of start_index to edit the body below a heading, up to the next heading of equal or shallower level. text is rendered as Markdown and replaces that body; end_of_segment=true appends instead. Formatting parameters without text format the whole body.

For ordinary header/footer text, prefer update_doc_headers_footers. Only pass segment_id when you already have a real header/footer/footnote segment ID from inspect_doc_structure output. Do not guess IDs such as "kix.header" or "kix.footer".

Input Schema

NameRequiredDescriptionDefault
boldNoWhether to make text bold (True/False/None to leave unchanged)
textNoNew text to insert or replace with (optional - can format existing text without changing it). Rendered as Markdown when heading is set.
italicNoWhether to make text italic (True/False/None to leave unchanged)
tab_idNoOptional document tab ID to target (required with heading when the doc has multiple tabs)
headingNoText of a body heading (case-insensitive, must match exactly one) whose section to edit instead of start_index/end_index
link_urlNoHyperlink URL (http/https)
end_indexNoEnd position for text replacement/formatting (if not provided with text, text is inserted)
font_sizeNoFont size in points
underlineNoWhether to underline text (True/False/None to leave unchanged)
clear_linkNoRemove hyperlink from the target range
segment_idNoOptional header/footer/footnote segment ID to target
small_capsNoWhether to apply small caps
text_colorNoForeground text color (#RRGGBB)
document_idYesID of the document to update
font_familyNoFont family name (e.g., "Arial", "Times New Roman")
font_weightNoFont weight (100-900 in steps of 100; requires font_family)
start_indexNoStart position for operation using Docs API indices from inspect_doc_structure. For the main body, 0 is also accepted as an alias for the first writable position. Required unless heading is set.
heading_levelNoOptional 1-6 heading level to narrow the heading match
strikethroughNoWhether to strike through text (True/False/None to leave unchanged)
end_of_segmentNoInsert text at the end of the targeted segment instead of start_index
baseline_offsetNoOne of NONE, SUPERSCRIPT, SUBSCRIPT
background_colorNoBackground/highlight color (#RRGGBB)
user_google_emailYesUser's Google email address

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.2.0
    • addedInput schema / properties / heading
      Added value: +{
+  "default": null,
+  "description": "Text of a body heading (case-insensitive, must match exactly one) whose\nsection to edit instead of start_index/end_index",
+  "type": "string"
+}
    • addedInput schema / properties / heading_level
      Added value: +{
+  "default": null,
+  "description": "Optional 1-6 heading level to narrow the heading match",
+  "type": "integer"
+}
    • addedInput schema / properties / start_index / default
      Added value: +null
    • changedInput schema / properties / start_index / description
      Previous value: -"Start position for operation using Docs API indices from\ninspect_doc_structure. For the main body, 0 is also accepted as an\nalias for the first writable position."New value: +"Start position for operation using Docs API indices from\ninspect_doc_structure. For the main body, 0 is also accepted as an\nalias for the first writable position. Required unless heading is set."
    • changedInput schema / properties / tab_id / description
      Previous value: -"Optional document tab ID to target"New value: +"Optional document tab ID to target (required with heading when the doc has multiple tabs)"
    • changedInput schema / properties / text / description
      Previous value: -"New text to insert or replace with (optional - can format existing text without changing it)"New value: +"New text to insert or replace with (optional - can format existing text without changing it).\nRendered as Markdown when heading is set."
    • changedInput schema / required
      Previous value: -[
-  "user_google_email",
-  "document_id",
-  "start_index"
-]New value: +[
+  "user_google_email",
+  "document_id"
+]
  2. Changed1 schema field changedv1.24.0
    • changedInput schema / properties / font_size / type
      Previous value: -"integer"New value: +"number"
  3. Addedv1.0.1

TDQS

A4.3/5.0
Behavior4/5

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

The description discloses meaningful behavior beyond the annotations: heading mode replaces the matched heading body, end_of_segment appends instead, text is Markdown-rendered in heading mode, and formatting parameters without text format the whole body. The annotations already cover the destructive/write nature, but the description adds little about permissions, reversibility, or error behavior.

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?

The description is front-loaded with the core operation and then organized into targeted mode-specific guidance, making it easy for an agent to scan. It is appropriately sized for a 23-parameter tool, though a few sentences could be slightly tighter.

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 complex, destructive document mutation tool with 23 parameters and an output schema, the description covers the main editing modes and a significant segment_id pitfall. It is largely complete, though it leaves some edge-case interactions unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics: heading replaces start_index, segment_id should only be passed with a real ID from inspect_doc_structure, and end_of_segment avoids index calculation. It does not explain every formatting parameter, but those are already well documented in the schema.

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: it modifies text in a Google Doc, including insert/replace operations and formatting in one call. It also distinguishes the heading-based editing mode and names update_doc_headers_footers as the preferred alternative for header/footer text, so an agent can separate it from key siblings.

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 gives explicit operational guidance: use end_of_segment to append without index math, use heading mode instead of start_index to edit a heading section, and prefer update_doc_headers_footers for ordinary header/footer edits. It does not fully position the tool against all other document-mutation siblings such as find_and_replace_doc or batch_update_doc, which keeps it from a 5.

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