Skip to main content
Glama

Update Spreadsheet

update_spreadsheet
Destructive

Write data to a range in an existing Google Sheet. The range must reference a tab that already exists (e.g. 'Overview!A1' requires an 'Overview' tab). Errors with 'Unable to parse range' if the tab name is unknown — call add_sheet_tab first to create new tabs. Values are stored EXACTLY AS GIVEN by default, so '=B1+B2' is saved as text and does not calculate; pass value_input_option='USER_ENTERED' to write real formulas. The result carries formula_notice when cells starting with '=' were stored as text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rangeYesA1 notation range e.g. 'Sheet1!A1:C10'
data_jsonYesJSON-encoded 2D array of cell values
clear_firstNoIf true clear the range before writing. Defaults to false.
spreadsheet_idYesThe spreadsheet ID
value_input_optionNoHow to interpret the values. 'RAW' (default) stores every value exactly as given, so '=B1+B2' is stored as the literal text and does NOT compute. 'USER_ENTERED' parses values the way typing them would, so formulas evaluate and dates are recognised. Use USER_ENTERED when the sheet is meant to calculate.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes'ok' when the write landed; 'not_shared' when Google would not acknowledge the spreadsheet — nothing was written, and the result text says how to recover
updated_rowsYesRows changed
updated_cellsYesCells changed
updated_rangeYesThe fully-qualified range Google wrote, including the tab name. Compare this against the tab you intended — a range with no tab prefix goes to the FIRST sheet.
formula_noticeNoPresent only when cells beginning with '=' were written as literal text because value_input_option was RAW. Those cells will NOT compute. Rewrite the range with value_input_option='USER_ENTERED' if formulas were intended.
spreadsheet_idYesThe spreadsheet that was written
updated_columnsYesColumns changed

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / status / description
      Previous value: -"Always 'ok' — a failure arrives as an error"New value: +"'ok' when the write landed; 'not_shared' when Google would not acknowledge the spreadsheet — nothing was written, and the result text says how to recover"
  2. Changed1 schema field changed
    • removedOutput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations (destructiveHint true), the description discloses the exact 'RAW' storage behavior, the fact that '=B1+B2' is stored as literal text unless USER_ENTERED is passed, the specific 'Unable to parse range' error mode, and the formula_notice result field. This is substantial behavioral context that annotations do not provide.

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 description is front-loaded with the core purpose, then each sentence adds a distinct constraint or behavior. There is no filler or redundancy, and the most important caveats (tab existence, formula handling, error notice) are compactly presented.

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?

Given the existing output schema, 100% parameter documentation, and destructiveHint annotation, the description covers the remaining operational details an agent needs: prerequisites, failure modes, formula behavior, and result notice. No critical gap remains for correct invocation.

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 baseline is 3, but the description goes further: it explains that range must reference an existing tab, gives the error behavior when it doesn't, and clarifies the practical difference between RAW and USER_ENTERED beyond the schema text. It doesn't add new meaning to spreadsheet_id or data_json, so not a 5.

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?

Description opens with 'Write data to a range in an existing Google Sheet', a specific verb+resource that clearly distinguishes it from sibling tools like create_spreadsheet, add_sheet_tab, update_document, and update_presentation. The mention of tab-qualified ranges and Google Sheets further scopes the tool.

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?

It explicitly tells the agent to call add_sheet_tab first when the target tab doesn't exist, which is a direct when/alternative statement. The phrase 'existing Google Sheet' and the tab-existence rule make it clear when this tool is appropriate versus creating a spreadsheet or adding a tab.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources