mcp-google-sheets

add_rows

Destructive

Adds specified number of rows to a Google Sheet at a given starting position. Use to insert blank rows for data entry or automation.

Instructions

Add rows to a sheet in a Google Spreadsheet.

Args: spreadsheet_id: The ID of the spreadsheet (found in the URL) sheet: The name of the sheet count: Number of rows to add start_row: 0-based row index to start adding. If not provided, adds at the beginning.

Returns: Result of the operation

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>",
      "sheet": "<sheet>",
      "count": "<count>"
    },
    "name": "add_rows"
  }
}

Input Schema

Name	Required	Description	Default
`spreadsheet_id`	Yes
`sheet`	Yes
`count`	Yes
`start_row`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.2Jun 21, 2026

TDQS

B3.3/5.0

Behavior3/5

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

The annotation already indicates destructiveHint=true. The description adds that rows are added and, if start_row is omitted, rows are added at the beginning. It does not disclose potential side effects like shifting existing rows, permissions required, or what the 'Result of the operation' entails.

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 (three sentences plus Returns line) and front-loads the purpose. The Returns line is generic, but overall structure is clear and efficient without superfluous text.

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?

Covers purpose and parameter meaning but lacks details on return value specifics, error conditions, limitations, or comparison with sibling tools. Given the complexity (4 params, destructive hint, output schema exists), the description is adequate but not fully complete.

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?

With 0% schema coverage, the description compensates by explaining each parameter: spreadsheet_id points to URL, sheet is name, count is number of rows, start_row is 0-based index with default behavior. This adds significant meaning beyond the schema's type-only definitions.

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 it adds rows to a Google Spreadsheet sheet. However, it does not explicitly differentiate from the sibling tool 'append_rows', which likely appends at the end, but the mention of 'start_row' implies insertion at a specific position, providing some distinction.

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?

No guidance on when to use this tool versus alternatives like 'append_rows' or other row manipulation tools. The description only explains parameter behavior (e.g., start_row default) but not the context for tool selection.

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