DataToRAG

gws-mcp__sheets_batch_update

Destructive

Apply a batch of structural and formatting changes to a spreadsheet, in ONE atomic call. This is the full Google Sheets batchUpdate pass-through and the escape hatch beneath the job-shaped tools: reach for sheets_format_range or sheets_format_table first, and come here for anything they do not cover (merges, borders, banding, copyPaste, inserting or deleting COLUMNS, duplicateSheet, protected ranges). TWO PROPERTIES THAT BITE. (1) Ranges here are a GridRange, which is 0-BASED and END-EXCLUSIVE: spreadsheet row 7 is startRowIndex 6, endRowIndex 7. That is the opposite convention from the A1 notation used to write the values. (2) The batch is ATOMIC: if one request is rejected the whole batch applies nothing, and the error names the failing request's index. Build the whole pass as one batch, fix the named index, re-send the whole thing. Note that empty reply objects are normal for formatting requests and mean ACCEPTED, not applied to what you meant.

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": {
      "spreadsheet_id": "<spreadsheet_id>",
      "requests": "<requests>"
    },
    "name": "gws-mcp__sheets_batch_update"
  }
}

Input Schema

Name	Required	Description
`account`	No	Optional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
`requests`	Yes	Array of Sheets API batchUpdate request objects, applied in order. Common ones: updateSheetProperties (freeze rows, hide gridlines, tab colour), updateDimensionProperties (column width, row height), insertDimension and deleteDimension (add or remove rows and columns, and these SHIFT every index after them, so put them first), repeatCell (fonts, colour, wrap, alignment, number format), mergeCells, updateBorders, copyPaste, duplicateSheet. Example: [{ "updateDimensionProperties": { "range": { "sheetId": 0, "dimension": "COLUMNS", "startIndex": 1, "endIndex": 4 }, "properties": { "pixelSize": 400 }, "fields": "pixelSize" } }]
`spreadsheet_id`	Yes	The spreadsheet ID

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag a destructive write, but the description goes well beyond them: it discloses atomic all-or-nothing failure behavior, that the error names the failing request index, the recovery loop (fix index, re-send whole batch), and that empty reply objects mean ACCEPTED. It also warns that insert/delete operations shift row and column indices.

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?

Front-loaded with one-line purpose, then a routing rule, then a numbered 'properties that bite' block, so an agent can stop reading at any tier. Dense and mostly waste-free, though the all-caps emphasis and the closing sentence about empty replies are slightly informal and could be tightened.

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?

No output schema exists, and the description compensates by explaining what empty replies mean and how errors surface. For a destructive, index-sensitive batch tool with an untyped request array, it covers the traps an agent must know: coordinate convention, ordering effects, and atomic rollback.

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 meaning the schema lacks: the critical GridRange convention (0-BASED, END-EXCLUSIVE, with a concrete row-7 example) and the warning that insertDimension/deleteDimension shift every subsequent index. Those are genuinely new semantics for the opaque 'requests' array.

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?

States a specific verb and resource ('Apply a batch of structural and formatting changes to a spreadsheet') plus the defining property ('in ONE atomic call'). It explicitly positions itself as the pass-through beneath 'job-shaped tools', which separates it from sheets_format_range and sheets_format_table in the sibling list.

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

Usage Guidelines5/5

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

Gives an explicit routing rule: try sheets_format_range or sheets_format_table first, come here for anything they do not cover. It then enumerates the uncovered operations (merges, borders, banding, copyPaste, insert/delete columns, duplicateSheet, protected ranges), so the agent knows precisely when this tool is the right choice.

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

All DataToRAG tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.