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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: formulas resolve to their displayed value, and there is a hard 10,000-cell ceiling per call with the recommended workaround.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The core action and range format come first, then the two behavioral facts (formula resolution, cell cap) that actually change how an agent calls it.

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

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

For a read tool with annotations covering safety and no output schema, the description covers what the return values mean (formula display values) and the operational limit. Only minor gaps remain, such as no mention of auth/mailbox prerequisites, which the schema partially covers.

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

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

Schema coverage is 67% and the range parameter's own schema description already documents A1 notation and bare-tab behavior, so the description's examples largely duplicate structured data. spreadsheetId and mailbox are not elaborated in the description at all, leaving the coverage gap unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Read cell values from an A1 range") with concrete scope examples, so the agent immediately knows what it does. It doesn't explicitly contrast itself with the parallel read_excel_range sibling, but the range/A1 framing plus the tool name makes the Sheets-vs-Excel split inferable.

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

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

It gives useful scope guidance ("ask for a narrower range rather than a whole large sheet"), which implies when a call is appropriate. However, it never states when to prefer this over get_google_spreadsheet or read_excel_range, nor any preconditions, so usage is only partially directed.

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