Fetches spreadsheet metadata such as sheets, properties, and named ranges. Use it to review structure before making edits.
Gets metadata about a spreadsheet including its sheets, properties, and named ranges
| Name | Required | Description | Default |
|---|---|---|---|
| spreadsheet_id | Yes | The ID of the spreadsheet |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully discloses the payload shape (sheets, properties, named ranges), but adds nothing about auth needs, scope errors, or limits beyond that.
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?
One front-loaded sentence with zero filler; the returned content is listed immediately after the purpose. Nothing is extraneous.
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 low-complexity read-only metadata fetch with no output schema, the enumerated return contents give the agent enough to know what it will receive. Only the sibling-differentiation gap and lack of access-error detail keep it from being fully complete.
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?
There is a single parameter with 100% schema description coverage ('The ID of the spreadsheet'), so the schema carries the semantics. The description adds no format hints or sourcing guidance (e.g., how to obtain the ID), so the baseline 3 applies.
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+resource ('Gets metadata about a spreadsheet') and enumerates what the metadata contains (sheets, properties, named ranges). However, it does not distinguish itself from close siblings like sheets_get_sheet_metadata or sheets_list_named_ranges, whose scopes overlap with the listed contents.
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?
There is no guidance on when to use this tool versus alternatives such as sheets_get_sheet_metadata or sheets_list_named_ranges. The agent is left to infer that this is the broad lookup while the siblings are narrower.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.