Skip to main content
Glama

sheets read range

sheets_read_range
Read-onlyIdempotent

Read cell values from an A1 range or named range in Google Sheets; row, column, and cell truncation flags show any limits applied.

Instructions

Read cell values from an A1 range (a1_range) such as 'Sheet1!A1:D20'.

Accepts A1 ranges, a sheet title, or a named range. The request is bounded before it is sent: at most max_rows rows (default 200, ceiling 2000) and 52 columns, cell text capped at 1000 characters. truncated, columns_truncated, and cells_truncated report cuts.

Input Schema

NameRequiredDescriptionDefault
a1_rangeYes
max_rowsNo
spreadsheet_idYes
value_render_optionNoFORMATTED_VALUE

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

Despite annotations already declaring readOnly/idempotent/non-destructive, the description adds substantive behavior beyond them: bounding happens before the request is sent, at most max_rows rows (default 200, ceiling 2000), 52 columns, cell text capped at 1000 characters. It also names the truncation signals returned, which an agent needs to detect partial results.

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?

Three tight sentences: operation and identifier first, then accepted range forms, then limits, then truncation reporting. No filler, and the most decision-relevant constraints are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is unnecessary, and the description still names the truncation fields that matter. The one real gap is silent handling of value_render_option, which affects what cell values are actually returned.

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 0%, so the description must compensate. It does well for a1_range (format example, sheet title, named range) and max_rows (default and ceiling), but says nothing about value_render_option's meaning or valid values, and spreadsheet_id is left unelaborated.

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?

States a specific verb and resource ('Read cell values from an A1 range') plus a concrete example range, so an agent immediately understands the operation. It does not explicitly distinguish itself from the sibling sheets_get_spreadsheet (metadata vs. cell values), leaving that separation to inference.

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?

The description clarifies accepted input forms ('A1 ranges, a sheet title, or a named range'), which is really input guidance rather than when-to-use guidance. There is no statement of when to prefer this over sheets_get_spreadsheet or when to avoid it, so usage is only implied by the purpose.

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