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

Update Paragraph Style

update_paragraph_style

Apply paragraph formatting, heading styles, and lists to a range in Google Docs. Control alignment, spacing, indentation, and more in a single call.

Instructions

Apply paragraph-level formatting, heading styles, and/or list formatting to a range in a Google Doc.

This tool can apply named heading styles (H1-H6) for semantic document structure, create bulleted or numbered lists with nested indentation, and customize paragraph properties like alignment, spacing, and indentation. All operations can be applied in a single call.

Input Schema

TableJSON Schema

Name	Required	Description
`tab_id`	No	Optional document tab ID to target
`alignment`	No	Text alignment - 'START' (left), 'CENTER', 'END' (right), or 'JUSTIFIED'
`direction`	No	Paragraph direction - 'LEFT_TO_RIGHT' or 'RIGHT_TO_LEFT'
`end_index`	Yes	End position (exclusive) - should cover the entire paragraph
`list_type`	No	Create a list from existing paragraphs ('UNORDERED' for bullets, 'ORDERED' for numbers, 'CHECKBOX' for checklists), or 'NONE' to remove existing list formatting from the range. Use 'NONE' when text inserted after a list has inherited its bullets: setting named_style_type or heading_level does not clear list membership, only 'NONE' does.
`indent_end`	No	Right/end indent in points
`segment_id`	No	Optional header/footer/footnote segment ID to target
`border_dash`	No	Border dash style ('SOLID', 'DOT', or 'DASH'; defaults to 'SOLID')
`document_id`	Yes	Document ID to modify
`space_above`	No	Space above paragraph in points (e.g., 12 for one line)
`space_below`	No	Space below paragraph in points
`start_index`	Yes	Start position using Docs API indices from inspect_doc_structure. For the main body, 0 is also accepted as an alias for the first writable position.
`border_color`	No	Border color (#RRGGBB; defaults to black)
`border_edges`	No	Paragraph border edges to update ('top', 'bottom', 'left', 'right', or 'between'); omit to update all four outer edges
`border_width`	No	Border width in points (defaults to 1)
`indent_start`	No	Left/start indent in points
`line_spacing`	No	Line spacing multiplier (1.0 = single, 1.5 = 1.5x, 2.0 = double)
`spacing_mode`	No	'NEVER_COLLAPSE' or 'COLLAPSE_LISTS'
`bullet_preset`	No	Optional explicit Google Docs bullet preset
`heading_level`	No	Heading level 0-6 (0 = NORMAL_TEXT, 1 = H1, 2 = H2, etc.) Use for semantic document structure
`shading_color`	No	Paragraph shading/background color (#RRGGBB)
`border_padding`	No	Border padding in points (defaults to 4)
`keep_with_next`	No	Keep the paragraph with the next paragraph
`named_style_type`	No	Direct named style type - 'NORMAL_TEXT', 'TITLE', 'SUBTITLE', 'HEADING_1' through 'HEADING_6'. Mutually exclusive with heading_level.
`indent_first_line`	No	First line indent in points (e.g., 36 for 0.5 inch)
`page_break_before`	No	Start the paragraph on a new page
`user_google_email`	Yes	User's Google email address
`list_nesting_level`	No	Nesting level for lists (0-8, where 0 is top level, default is 0) Use higher levels for nested/indented list items
`keep_lines_together`	No	Keep all lines of the paragraph together
`avoid_widow_and_orphan`	No	Avoid widows/orphans for the paragraph

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.26.0Sep 6, 2026

changedInput schema / properties / list_type / description

Previous value: -"Create a list from existing paragraphs ('UNORDERED' for bullets, 'ORDERED' for numbers, 'CHECKBOX' for checklists)"New value: +"Create a list from existing paragraphs ('UNORDERED' for bullets, 'ORDERED' for numbers, 'CHECKBOX' for checklists), or 'NONE' to remove existing list formatting from the range. Use 'NONE' when text inserted after a list has inherited its bullets: setting named_style_type or heading_level does not clear list membership, only 'NONE' does."

Changed5 schema fields changedv1.24.0Aug 13, 2026

addedInput schema / properties / border_color

Added value: +{
+  "default": null,
+  "description": "Border color (#RRGGBB; defaults to black)",
+  "type": "string"
+}

addedInput schema / properties / border_dash

Added value: +{
+  "default": null,
+  "description": "Border dash style ('SOLID', 'DOT', or 'DASH'; defaults to 'SOLID')",
+  "type": "string"
+}

addedInput schema / properties / border_edges

Added value: +{
+  "default": null,
+  "description": "Paragraph border edges to update ('top', 'bottom', 'left',\n          'right', or 'between'); omit to update all four outer edges",
+  "items": {
+    "enum": [
+      "top",
+      "bottom",
+      "left",
+      "right",
+      "between"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / border_padding

Added value: +{
+  "default": null,
+  "description": "Border padding in points (defaults to 4)",
+  "type": "number"
+}

addedInput schema / properties / border_width

Added value: +{
+  "default": null,
+  "description": "Border width in points (defaults to 1)",
+  "type": "number"
+}

Addedv1.0.1Jul 31, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already indicate this is a mutation (readOnlyHint false) and not idempotent. The description adds no behavioral detail beyond that—it does not mention whether existing formatting is overwritten or merged, or any side effects. It simply states 'apply', which is consistent with annotations but adds no extra transparency.

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 concise, with the main purpose stated first and a brief list of capabilities. It is efficient and front-loaded, though it could be slightly more structured by separating the capabilities from the general action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (30 parameters, mutation, output schema exists), the description is adequate but sparse. It doesn't mention prerequisites like needing indices from inspect_doc_structure, nor does it differentiate between heading_level and named_style_type. The parameter schemas cover details, but the overall usage context is thin.

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%, so each parameter already has a detailed description. The tool description does not add any parameter-specific meaning beyond what the schema 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (apply) and resource (paragraph-level formatting to a range in Google Doc), and enumerates specific capabilities (heading styles, lists, alignment, spacing, indentation). It is specific enough to distinguish from text modification tools like modify_doc_text, though it does not explicitly name an alternative.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as batch_update_doc or insert_doc_elements. It only mentions that all operations can be applied in a single call, which is a minor efficiency note but not usage direction.

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

Deploy Server