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

Format Sheet Range

format_sheet_range

Destructive

Applies formatting to a Google Sheets range, including colors, number formats, alignment, text styles, borders, merged cells, and dropdown lists.

Instructions

Applies formatting to a range: colors, number formats, text wrapping, alignment, text styling, cell merging/unmerging, borders, and dropdown lists.

Colors accept hex strings (#RRGGBB). Number formats follow Sheets types (e.g., NUMBER, CURRENCY, DATE, PERCENT). If no sheet name is provided, the first sheet is used.

Input Schema

Name	Required	Description
`bold`	No	Whether to apply bold formatting.
`italic`	No	Whether to apply italic formatting.
`borders`	No	Which borders to draw, comma-separated: all, outer, inner, top, bottom, left, right, inner_horizontal, inner_vertical (e.g., "outer" or "bottom,inner_horizontal"). "none" removes every border in the range.
`font_size`	No	Font size in points.
`merge_type`	No	MERGE_ALL (default), MERGE_COLUMNS, or MERGE_ROWS. Setting it implies merge_cells=True.
`range_name`	Yes	A1-style range (optionally with sheet name). Required.
`text_color`	No	Hex text color (e.g., "#000000").
`merge_cells`	No	True merges the range, False unmerges it. Merging keeps only the top-left value of each merged group.
`border_color`	No	Hex border color (default black). Requires borders.
`border_style`	No	SOLID (default), SOLID_MEDIUM, SOLID_THICK, DASHED, DOTTED, or DOUBLE. Requires borders.
`wrap_strategy`	No	Text wrap strategy - WRAP (wrap text within cell), CLIP (clip text at cell boundary), or OVERFLOW_CELL (allow text to overflow into adjacent empty cells).
`clear_dropdown`	No	Remove all data validation from the range: dropdowns, but also checkboxes and other validation rules.
`spreadsheet_id`	Yes	The ID of the spreadsheet. Required.
`dropdown_strict`	No	With dropdown_values: reject other input (default True) or only show a warning (False).
`dropdown_values`	No	Turns every cell in the range into a dropdown offering these values (e.g., ["open", "done"]).
`background_color`	No	Hex background color (e.g., "#FFEECC").
`user_google_email`	Yes	The user's Google email address. Required.
`number_format_type`	No	Sheets number format type (e.g., "DATE").
`vertical_alignment`	No	Vertical text alignment - TOP, MIDDLE, or BOTTOM.
`horizontal_alignment`	No	Horizontal text alignment - LEFT, CENTER, or RIGHT.
`number_format_pattern`	No	Custom pattern for the number format.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv2.2.0Oct 24, 2026

addedInput schema / properties / border_color

Added value: +{
+  "default": null,
+  "description": "Hex border color (default black). Requires\nborders.",
+  "type": "string"
+}

addedInput schema / properties / border_style

Added value: +{
+  "default": null,
+  "description": "SOLID (default), SOLID_MEDIUM, SOLID_THICK,\nDASHED, DOTTED, or DOUBLE. Requires borders.",
+  "type": "string"
+}

addedInput schema / properties / borders

Added value: +{
+  "default": null,
+  "description": "Which borders to draw, comma-separated: all,\nouter, inner, top, bottom, left, right, inner_horizontal,\ninner_vertical (e.g., \"outer\" or \"bottom,inner_horizontal\").\n\"none\" removes every border in the range.",
+  "type": "string"
+}

addedInput schema / properties / clear_dropdown

Added value: +{
+  "default": null,
+  "description": "Remove all data validation from the\nrange: dropdowns, but also checkboxes and other validation rules.",
+  "type": "boolean"
+}

addedInput schema / properties / dropdown_strict

Added value: +{
+  "default": null,
+  "description": "With dropdown_values: reject other\ninput (default True) or only show a warning (False).",
+  "type": "boolean"
+}

addedInput schema / properties / dropdown_values

Added value: +{
+  "default": null,
+  "description": "Turns every cell in the range into\na dropdown offering these values (e.g., [\"open\", \"done\"]).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / merge_cells

Added value: +{
+  "default": null,
+  "description": "True merges the range, False unmerges it.\nMerging keeps only the top-left value of each merged group.",
+  "type": "boolean"
+}

addedInput schema / properties / merge_type

Added value: +{
+  "default": null,
+  "description": "MERGE_ALL (default), MERGE_COLUMNS, or\nMERGE_ROWS. Setting it implies merge_cells=True.",
+  "type": "string"
+}

Changed20 schema fields changedv1.28.0Sep 24, 2026
- removedInput schema / properties / background_color / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / background_color / type
```
Added value: +"string"
```
- removedInput schema / properties / bold / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / bold / type
```
Added value: +"boolean"
```
- removedInput schema / properties / font_size / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / font_size / type
```
Added value: +"integer"
```
- removedInput schema / properties / horizontal_alignment / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / horizontal_alignment / type
```
Added value: +"string"
```
- removedInput schema / properties / italic / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / italic / type
```
Added value: +"boolean"
```
- removedInput schema / properties / number_format_pattern / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / number_format_pattern / type
```
Added value: +"string"
```
- removedInput schema / properties / number_format_type / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / number_format_type / type
```
Added value: +"string"
```
- removedInput schema / properties / text_color / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / text_color / type
```
Added value: +"string"
```
- removedInput schema / properties / vertical_alignment / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / vertical_alignment / type
```
Added value: +"string"
```
- removedInput schema / properties / wrap_strategy / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / wrap_strategy / type
```
Added value: +"string"
```
Addedv1.0.1Jul 31, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the description can add the promotion of the default-sheet fallback and hex/format conventions. However, it never warns that this mutation is destructive (merging discards values, clearing dropdowns removes checkboxes and other validation) and never explains the non-idempotent character, which are exactly the disclosures an agent needs for a format-write tool.

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?

Two tight paragraphs, front-loaded with the operation and its capability scope, followed by format conventions. No filler, though the hex-format sentence is largely redundant with the schema.

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?

With 21 parameters, destructive annotations and an output schema, the description covers the overall operation and conventions well enough to call the tool. It is still incomplete on the risk side: nothing tells the agent that merges drop data or that clear_dropdown also strips checkboxes and other validation rules, which are the consequences most likely to cause harm.

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 baseline is 3 and the schema already documents every one of the 21 parameters in detail. The description adds almost nothing beyond the schema: its hex-color and number-format-type notes restate what the parameter descriptions already say, and only the 'first sheet is used' fallback for range_name is genuinely new.

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 first sentence names a specific verb (Applies formatting) and enumerates the resource and the formatting categories (colors, number formats, wrapping, alignment, styling, merging, borders, dropdowns). It is clear what the tool does, but it never mentions how it differs from nearby siblings such as manage_conditional_formatting or modify_sheet_values, so an agent must infer the boundary.

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?

Usage is only implied by the enumerated capability list; there is no explicit when-to-use or when-not-to-use statement and no named alternative. The one scoping rule given ('If no sheet name is provided, the first sheet is used') is helpful but is a behavior, not a selection guideline.

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

Deploy Server