Skip to main content
Glama
Matthew3957

ai-toolkit

by Matthew3957

insert_sheet_rows

Insert blank rows at any position in a Google Sheet, pushing existing content down instead of overwriting it. Optionally fill the new rows with values in the same call.

Instructions

Insert blank rows at a position, shifting existing rows down.

This is the one placement that update_sheet_range can't do: it makes room by pushing existing rows down instead of overwriting them. Use it to prepend at the top, or to insert into a sorted region. If values is given, the freshly inserted rows are populated in the same call.

sheet_id is the spreadsheet's ID (from its URL) and is required. tab is the worksheet title (see list_sheet_tabs). row_index is the 1-based row number the inserted rows will occupy — content currently at that row and below shifts down. Use 1 to insert above everything; with a header in row 1, pass 2 to insert just below it. values is an optional list of rows (each a list of cell strings) to write into the new space; the number of rows inserted matches its length (or 1 blank row when omitted). value_input_option USER_ENTERED parses dates/numbers/formulas like typing; RAW stores text verbatim. Returns a summary of what was inserted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tabYes
valuesNo
sheet_idYes
row_indexYes
value_input_optionNoUSER_ENTERED

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior4/5

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

Since no annotations are provided, the description takes full responsibility. It transparently discloses side effects (shifting rows down, populating when values given), explains value_input_option behavior (parsing vs verbatim), and notes the return summary. It does not admit limitations like irreversibility or permissions, but for a spreadsheet insertion this is sufficient and consistent.

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?

Although longer than typical, every sentence adds value: purpose, differentiation, usage, parameter details, and return info. The structure front-loads the core action and then elaborates. There is zero redundancy or filler.

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?

For a mutation tool with 5 parameters, no annotations, and an output schema, the description covers all necessary aspects: when to use, parameter semantics, edge cases (header row), and result summary. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining every parameter: sheet_id from URL, tab from list_sheet_tabs, row_index as 1-based with shift semantics, values as optional list determining row count, and value_input_option behavior. This is exemplary compensation for a schema with no descriptions.

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?

The description clearly states a specific action ('Insert blank rows at a position, shifting existing rows down') and the resource (a spreadsheet sheet). It explicitly distinguishes itself from update_sheet_range by explaining what that sibling cannot do, leaving no ambiguity about its unique role.

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?

Provides concrete when-to-use guidance ('prepend at the top, or to insert into a sorted region') and explains the difference from update_sheet_range. Even gives a practical example (header row handling) and mentions the alternative tool by name, covering both use and exclusion contexts.

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