mcp-gsheets
Server Quality Checklist
Latest release: v1.10.1
- Disambiguation3/5
There is notable overlap among read tools (e.g., sheets_get_sheet_structure, sheets_get_sheet_dimensions, sheets_get_merged_cells, sheets_get_full_sheet_snapshot, sheets_get_formatting_compact) that return similar structural or formatting data. Write tools like sheets_insert_rows and sheets_append_values also have subtly different semantics. Detailed descriptions mitigate confusion, but the boundaries are not always crisp.
Naming Consistency4/5All tools follow a consistent sheets_verb_noun pattern with snake_case, and prefixes like batch_ and get_ are used systematically. The only minor deviation is sheets_copy_to, where 'to' is not a noun, but the overall naming remains predictable and readable.
Tool Count2/5At 44 tools, the server is extremely heavy. Many operations are split into individual tools (e.g., separate single and batch variants, multiple formatting getters) that could be consolidated. The scope is broad, but the count exceeds what is typically manageable for an agent.
Completeness4/5The tool set offers comprehensive coverage for spreadsheet and sheet management, including values, formatting, charts, tables, data validation, filters, and structural modifications. Minor gaps exist, such as missing spreadsheet deletion and sharing/permission controls, but core workflows are fully supported.
Average 3.8/5 across 44 of 44 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare idempotentHint and destructiveHint, but the description adds no additional behavioral context. It does not explain whether rules are appended to existing ones, replace them, or how duplicates are handled. The idempotency hint is left uninterpreted, and no side effects, permissions, or rate limits are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise. However, it is so terse that it edges toward under-specification, lacking the detail needed to be genuinely useful. It is acceptable in size but not in substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a very complex input schema and no output schema, yet the description gives only a bare action statement. It fails to explain the rule types, range specifications, behavioral semantics, or return values. Given the complexity, this is critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters beyond their names in the schema. The rules parameter is highly complex with nested structures, and the description does not compensate at all, leaving the agent to rely entirely on the raw schema without any explanatory context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('conditional formatting rules to a Google Sheet'). It uses a specific verb and resource that distinguishes this from siblings like sheets_get_conditional_formatting or sheets_format_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, differences from other formatting tools, or scenarios where this should be preferred. The one-line description gives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide idempotentHint=true and destructiveHint=false, but the description adds no behavioral context beyond that. It fails to clarify whether unspecified border sides are preserved or cleared, or how to remove borders, which are important operational details for this mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, efficiently conveying the core purpose. While concise, it is slightly thin for the tool's complexity, so it does not reach a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested borders schema, no output schema, and many related siblings, the description is too sparse. It omits key details about partial border updates, clearing borders, and how this tool relates to formatting or border-reading tools, making it incomplete for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description bears full responsibility for parameter semantics but provides none. It does not explain the A1 range notation or the structure/meaning of the borders object, leaving the rich nested schema to stand alone without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Update') and resource ('borders of cells in a Google Sheet'), making the tool's function immediately understandable. However, it does not distinguish this tool from siblings like sheets_format_cells or sheets_get_border_map, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention exclusions, prerequisites, or related tools, leaving the agent without direction on tool selection beyond the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply restates the tool's name without adding behavioral context. While annotations already declare idempotentHint=true and destructiveHint=false, the description does not disclose what happens to cell values after merging (e.g., only the top-left value is kept) or any side effects. It adds no value beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the main verb. It is appropriately sized and free of unnecessary words, though its brevity comes at the cost of essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description is technically minimal but incomplete. It fails to explain the merge types, the required range format, or how this tool relates to siblings like 'sheets_unmerge_cells' and 'sheets_get_merged_cells', leaving the agent without sufficient context for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the three required parameters (spreadsheetId, range, mergeType). With 0% schema description coverage, the agent receives no explanation of how to specify the range or what each mergeType value means, making it impossible to correctly invoke the tool based solely on the description and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Merge cells') and the target resource ('a Google Sheet'), and it distinguishes this tool from the sibling 'sheets_unmerge_cells' which performs the opposite operation. The purpose is immediately understandable and specific enough for an agent to know what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it explain the differences between the three merge types (MERGE_ALL, MERGE_ROWS, MERGE_COLUMNS) defined in the schema. An agent is left without direction on how to select the appropriate merge type or when merging is preferable to other cell-formatting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the insert action itself, such as row shifting, formatting inheritance, or permission requirements. Annotations already indicate idempotent and non-destructive behavior, but the description fails to enrich them with any operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant information. It is concise but might benefit from structured addition of usage context; still, its brevity is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, two enums, and no output schema, this one-liner fails to provide essential context such as how rows shift relative to the anchor, what happens to existing data, or how the tool behaves with defaults. The description is too sparse for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all 7 parameters, including enums for position and valueInputOption. The description's phrase 'optional data' adds little beyond the schema's 'values' parameter, so it does not meaningfully compensate or extend.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Insert' targeting 'rows' with 'at a specific position' and 'optional data', which clearly distinguishes the operation from append (values at end) and sheet-level insertion. However, it does not explicitly mention the anchor mechanism or sibling tool names, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_append_values or sheets_insert_sheet. It does not state use cases, exclusions, or conditions, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral context beyond what annotations already declare. Annotations indicate idempotentHint=true and destructiveHint=false, and the description merely restates the core action without adding details like return value, permissions, or side effects. Since it adds no additional disclosure, it earns a below-baseline score despite having annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, lean sentence that directly conveys the tool's purpose without wasted words. It is appropriately sized for the tool's low complexity, front-loading the action and resource clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and a complete schema, the description is nearly sufficient, but it lacks any mention of return values (e.g., spreadsheet ID or URL), which is critical for a create operation. With no output schema, the description should have specified what the agent can expect as a result, making the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (title and sheets) fully described in the input schema. The description adds no extra meaning about parameters, such as constraints or behaviors, so the baseline of 3 is appropriate because the schema carries the full burden of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Google Sheets spreadsheet' clearly states the verb (create) and the resource (Google Sheets spreadsheet), which differentiates it from sibling tools like sheets_create_chart or sheets_insert_sheet. However, it does not explicitly elaborate on the scope or add value over the tool name, so it lacks the explicit sibling differentiation seen in top-tier examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_insert_sheet (for adding a sheet to an existing spreadsheet) or when not to use it. The description only states the action without any contextual usage instructions, leaving the agent to infer the appropriate situation from the schema and tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true and destructiveHint=false, but the description adds no additional behavioral context. It doesn't explain that inserting a link may overwrite existing cell content, how validation behaves, or what happens if the range covers multiple cells. The description carries little weight beyond the annotations themselves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler. However, it is extremely brief, and while it is efficient, it sacrifices informative details that could be structured into separate clauses. Still, for a simple, non-verbose description, it earns a high conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and a one-sentence description, the tool is under-specified. The description fails to mention important parameters like validation or useEUFormat, and lacks guidance on how ranges work or what the function returns. The schema compensates partially, but the description alone is not enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions 'custom display text,' which mirrors the 'text' parameter, but doesn't add new meaning beyond the schema's own parameter descriptions. No extra value is provided to help understand parameter interactions or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Insert clickable links in Google Sheets cells with custom display text.' It uses a specific verb ('insert'), specifies the resource ('links in Google Sheets cells'), and describes the key feature (custom display text). This distinguishes it from sibling tools like sheets_update_values or sheets_format_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or comparison to similar tools like sheets_update_values. The agent is left to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds no additional behavioral context (e.g., return format, pagination, or default behaviors) beyond what the name and schema imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It is front-loaded with the action and resource, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter, the description, combined with the complete schema and annotations, provides sufficient information. It could benefit from a note about using non-batch retrieval vs batch, but the tool is straightforward enough that this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the parameters, so the baseline is 3. The tool description does not add any extra semantics beyond the schema; all parameters are already well-documented with type and examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get values) and resource (specified range in a Google Sheets spreadsheet). It is unambiguous and functionally specific, but it does not explicitly distinguish itself from the sibling tool 'sheets_batch_get_values', which might offer multi-range retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sheets_batch_get_values or sheets_get_sheet_structure. The description simply states what it does without contextual usage clues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include idempotentHint: true, with no destructiveHint. The description does not disclose permanent deletion, row shifts, or permission requirements. The verb 'Delete' implies destructiveness, but no additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the essential operation and input format with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple delete tool, but lacks usage differentiation and side-effect disclosure. Given many sibling delete-related tools, more context about selection criteria and consequences would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (range and spreadsheetId) already well-documented. The description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Delete') with a clear resource ('rows from a Google Sheet') and specifies the input format ('full-row A1 range'). This clearly distinguishes it from sibling tools like sheets_delete_columns or sheets_delete_sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives such as sheets_delete_columns, sheets_delete_sheet, or sheets_clear_values. It does not mention prerequisites or context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the categories of formatting, not behavior such as whether existing formatting is overwritten or if specific permissions are needed, but it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence efficiently conveys the tool's purpose and key formatting areas without waste. It is appropriately sized for the annotation-rich context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested format schema and annotations, the description is minimally viable but lacks important context such as when to choose this over batch formatting or what happens to existing formats. The schema and annotations compensate partially, but the description alone is not fully complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 lists high-level categories (colors, fonts, alignment, number formats) that map to the format object's properties, aiding interpretation. However, it does not explain individual parameters like padding or wrapStrategy; the detailed schema carries most semantic weight, resulting in adequate but not strong compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool formats cells in a Google Sheet and lists the main formatting categories (colors, fonts, alignment, number formats). This is a specific verb+resource combination that distinguishes it from broader sheet operations, though it does not explicitly differentiate from the sibling sheets_batch_format_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sheets_batch_format_cells, nor any prerequisites such as access requirements or range formatting behavior. The description gives no contextual clues for selection beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds no behavioral context beyond the action itself, such as what constitutes a 'native table', whether it returns table metadata, or how it handles sheets without tables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and free of filler. It earns its place by defining the tool's scope and purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-documented parameters and readOnly annotations, the description is adequate but leaves ambiguity around the term 'native Google Sheets tables' and does not clarify what output to expect. More detail on the object being read would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both spreadsheetId and sheetName fully described in the schema. The description loosely references these parameters ('for a spreadsheet or a specific sheet') but adds no additional meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('native Google Sheets tables') with a scoping phrase ('for a spreadsheet or a specific sheet'). This distinguishes it from sibling tools like sheets_get_values (reads cell values) and sheets_get_sheet_structure (reads sheet layout).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention cases where other tools (e.g., sheets_get_values or sheets_get_sheet_structure) would be more appropriate, and no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotentHint annotation, the description adds no additional behavioral context. It does not disclose that deletion is permanent, irreversible, or requires specific permissions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and without redundancy. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters and no output schema. The description, while minimal, is sufficient for the core operation. However, it could be slightly more complete by mentioning the single-sheet scope or the permanence of deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having detailed descriptions. The tool description adds no extra parameter semantics, but the schema already carries the burden, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction ('Delete a sheet from a Google Sheets spreadsheet') that clearly states the tool's action and distinguishes it from sibling tools like sheets_delete_chart or sheets_delete_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention that this is for a single sheet while sheets_batch_delete_sheets handles multiple sheets, nor does it specify prerequisites like access requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the contents of the metadata returned (sheet names, IDs, properties), which is useful but does not reveal any additional behavioral traits or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without unnecessary words. It earns its place with specific detail about the returned metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with annotations, the description adequately explains what the tool returns. However, without an output schema, it could be more explicit about the exact structure or any additional metadata fields, leaving a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the spreadsheetId parameter well-documented in the schema. The tool description adds no extra meaning beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'metadata about a Google Sheets spreadsheet', listing specific contents (sheet names, IDs, properties). It is not explicitly differentiated from siblings like sheets_get_sheet_structure, but the scope is sufficiently clear and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as sheets_get_sheet_structure or sheets_get_values. The description only states what it does, without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With idempotentHint=true annotation, the description's scope is narrow. It does not contradict the annotation, but it also doesn't add behavioral details beyond the basic action, such as how it handles a range with partially merged cells or whether it's safe on non-merged ranges. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb 'Unmerge' and the target resource. Every word earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the core function, but it lacks detail on edge cases (e.g., what happens if the range contains no merged cells) and does not elaborate on parameter usage. Given the lack of output schema and minimal annotations, the description is sufficient for basic usage but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain spreadsheetId or range. While parameter names are self-explanatory to some extent, the description fails to provide any additional meaning or context, leaving parameter semantics solely to the names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the exact action ('Unmerge cells') and the resource ('a Google Sheet'), making it distinct from sibling tools like sheets_merge_cells. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., checking if cells are merged), and no mention of when not to use it. It only states the function without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the basic operation; it does not explain field mask semantics, that column definitions replace the entire table columns, or any side effects of the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no filler. It is front-loaded with the verb 'Update' and clearly identifies the resource and key identifier (tableId). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex tool with 7 parameters and a required field mask, yet the description is only one sentence. It does not explain how the field mask selects which properties to update, nor that column definitions replace all columns. The schema provides parameter details, but the overall operation semantics are not conveyed, leaving the agent to infer critical behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description itself adds no parameter-level meaning. Baseline of 3 is appropriate given complete schema coverage, but the description does not enhance understanding of field mask usage or parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Update an existing native Google Sheets table by tableId'. This clearly distinguishes the tool from siblings like sheets_add_table, sheets_delete_table, and sheets_get_tables, which correspond to other lifecycle operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'existing' indicates this is for modifying tables that already exist, which implicitly differentiates it from creation tools. However, there is no explicit guidance on when to use this versus alternatives like sheets_add_table or sheets_get_tables, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that the tool clears values, which implies a destructive write operation. The idempotentHint annotation already indicates repeatability, but the description adds no further behavioral context, such as whether formatting or notes are preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and target. It contains no redundant words, making it maximally concise while preserving clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter operation with a complete schema and idempotency annotation, the description is sufficient. It could slightly improve by noting that only values are cleared and not formatting, but the core behavior is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters (spreadsheetId and range) with clear descriptions, achieving 100% coverage. The description does not add any additional parameter-specific meaning or examples beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'clear' and identifies the resource as 'values in a specified range of a Google Sheets spreadsheet,' which clearly distinguishes it from sibling read, update, and append operations. It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like sheets_update_values or sheets_append_values. It also does not mention any prerequisites or exclusions, such as the fact that it only affects values and not formatting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include idempotentHint; no destructiveHint is provided. The description says 'Delete' but does not disclose consequences such as permanent data removal, shifting of remaining columns, or required permissions. This leaves a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a specific verb and resource. It is concise and free of filler, elegantly covering the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two fully described parameters, an idempotency hint, and no output schema, the description covers the essential purpose and scope. It does not discuss side effects, but given the low complexity, the core information is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter descriptions in the schema are already detailed (e.g., range example and spreadsheetId explanation). The tool description adds no extra parameter-level meaning beyond repeating the 'full-column A1 range' concept present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), resource ('columns from a Google Sheet'), and the specific method ('using a full-column A1 range'). It distinguishes from sibling tools like sheets_delete_rows and sheets_delete_sheet by specifying column deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for deleting columns and emphasizes the full-column range format, but it does not explicitly discuss when to use this tool versus alternatives (e.g., delete_rows, delete_sheet). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the verb 'delete' and the idempotentHint annotation. It does not mention that deletion is permanent, whether write permissions are required, what happens to associated data, or potential errors. For a destructive operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It states the essential action and method, earning full marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool with no output schema, the description omits important context: return behavior, error conditions, permission requirements, and irreversibility. The single sentence is too minimal to fully equip an agent, especially given the annotation only covers idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description essentially restates 'by tableId', adding no new semantic information beyond what the schema already provides. Baseline 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a native Google Sheets table by tableId' clearly states the action (delete), the resource (native Google Sheets table), and the identifying method (by tableId). This distinguishes it from sibling tools like sheets_delete_sheet and sheets_delete_chart, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for deleting tables (not sheets or charts) and specifies the identifying parameter. It does not explicitly mention alternatives or exclusions, but the resource type is unambiguous, and the context makes it clear when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint: true and destructiveHint: false, covering the safety profile. The description adds the batching behavior but does not disclose additional traits like overwriting existing formatting or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 12-word sentence that front-loads the purpose without any filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and annotations, the description is adequate for a straightforward batch formatting tool. However, it lacks guidance on constructing format objects and does not mention potential side effects like replacing existing formatting, leaving some gaps for complex use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (spreadsheetId and formatRequests) already described. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Format) and scope (multiple cell ranges in a Google Sheet), distinguishing it from the single-range sibling tool sheets_format_cells by emphasizing 'multiple' and 'in a single operation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batching ('multiple cell ranges', 'single operation') but does not explicitly state when to use this tool over alternatives like sheets_format_cells, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true and destructiveHint=false, and the description does not contradict these. The description adds context about range quoting and overlayPosition structure, but does not disclose side effects, permissions, or return value behavior, which with annotations present leaves the safety profile adequately covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, front-loaded with the core purpose, and every sentence adds meaningful guidance. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, nested objects), the description focuses on the most error-prone aspects. While it does not explain all options like axes or legends, the schema descriptions cover those. The absence of an output schema is mitigated by the clear annotation hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by centralizing the quoting rule for sheet names with spaces and clarifying the nested overlayPosition structure with anchorCell fields, which helps avoid common mistakes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a chart in a Google Sheets spreadsheet' with a specific verb and resource. It does not explicitly distinguish from sibling tools like sheets_update_chart or sheets_delete_chart, but the verb 'create' makes the primary purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating charts but does not provide explicit when-to-use versus alternatives such as updating or deleting charts. It includes useful tips about quoting sheet names and using overlayPosition, but these are more parameter handling than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation idempotentHint=true already signals that repeated deletes are safe. The description adds no extra behavioral context, such as whether the chart must exist, permissions required, or irreversibility. With annotations present, the bar is lower, but the description still does not go beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant information. It conveys the purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter deletion tool with no output schema and an idempotency annotation, the description is minimally adequate. However, it omits potential edge cases (e.g., behavior if the chart ID is invalid, whether deletion cascades to associated data). The shortcoming is modest, given the tool's simplicity, but it does not fully help the agent anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already explained. The chartId description even provides a hint to use sheets_get_metadata. The tool description itself adds no parameter insight beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('chart from a Google Sheets spreadsheet'), clearly distinguishing it from siblings like sheets_create_chart and sheets_update_chart. It is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no explicit guidance on when to use it versus alternatives. The context of deleting a chart is clear from the name, but there is no mention of prerequisites, such as the chart belonging to the given spreadsheet, or exclusions. No comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds minimal context beyond that: it states the operation is within the same spreadsheet, which is useful but does not clarify behavior like whether the original is preserved or what happens with existing data. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It immediately conveys the core purpose and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema cover the basic operation and parameters, but there is no output schema and no mention of edge cases (e.g., default new sheet name if not provided, behavior when the sheet name already exists). Given the tool's simplicity and annotation coverage, this is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameters, each with its own description. The tool description adds no additional parameter context, but since the schema already fully documents the parameters, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (duplicate), the resource (a sheet), and the context (within a Google Sheets spreadsheet). It is specific and distinct from sibling tools like 'sheets_insert_sheet' (creates an empty sheet) and 'sheets_copy_to' (copies to another spreadsheet).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to duplicate a sheet) but does not provide explicit guidance on when to choose this over alternatives, nor does it mention any prerequisites or exclusions. Sibling tools such as sheets_insert_sheet and sheets_copy_to exist, but no comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that the chart must exist ('existing'), but it does not disclose important update semantics such as whether omitted optional fields reset or preserve existing values. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes meaning, and it is immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema and annotations provide substantial detail, the description is very thin for a complex 13-parameter tool with nested objects. It does not clarify update semantics (partial merge vs. full replacement), error behavior for non-existent charts, or return values (no output schema exists). The description is minimally viable but leaves important behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with descriptive text for all 13 parameters, including enums and usage hints (e.g., chartId references sheets_get_metadata). The tool description itself adds no parameter-level insight, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing chart in a Google Sheets spreadsheet' uses a specific verb ('Update') and resource ('chart'), and the word 'existing' clearly distinguishes it from sheets_create_chart. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying an already-existing chart, but it does not explicitly state when to use this tool versus create/delete alternatives. The chartId parameter description does mention using sheets_get_metadata to find chart IDs, providing some operational guidance, but no explicit 'when not to use' is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the description does not need to repeat those safety traits. However, it adds no additional behavioral context, such as potential side effects, permissions required, or behavior on duplicate names. It is not misleading, but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any filler. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with full schema documentation and non-destructive annotations, the description provides sufficient context. It covers the essential action and distinguishing features, and the schema handles parameter specifics. The lack of output schema or explicit return value explanation is a minor gap, but not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters. The description adds no extra parameter details beyond mentioning 'typed columns and optional dropdown values,' which is already reflected in the columnType and dropdownValues fields. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'native Google Sheets table' with specific attributes (typed columns, optional dropdown values). It effectively distinguishes this tool from sibling tools like sheets_update_table, sheets_delete_table, and sheets_get_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a Google Sheets table, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The purpose is clear, but there is no direct comparison to related operations like updating or deleting tables.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe, idempotent behavior is covered. The description adds no further behavioral context, such as return format or rate limits, but it is consistent with the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant or filler words. It conveys the tool's core purpose immediately and saves the agent time.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read tool, the description is mostly sufficient, especially with detailed schema and annotations. However, since there is no output schema, it would be helpful to mention that the response returns a map of ranges to values, and that it is more efficient than multiple single-range calls. This minor gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 4 parameters, including clear definitions and examples for ranges, spreadsheetId, majorDimension, and valueRenderOption. The description itself adds no parameter-specific meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with resource 'values' and scope 'multiple ranges' in a Google Sheets spreadsheet. This clearly distinguishes it from sibling tools like sheets_get_values (single range) and write operations such as sheets_batch_update_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'multiple ranges' implies when to use this tool (when needing more than one range), but it does not explicitly state when not to use it or recommend alternatives such as sheets_get_values for single ranges. No exclusions or contrasting guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so safety profile is known. The description adds no additional behavioral context, such as how existing values in the ranges are affected or how valueInputOption influences interpretation. It neither contradicts annotations nor enriches them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and scope. Every word is purposeful, with no redundant details or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (batch operation with nested data) and the presence of a detailed schema, the description is sufficient to understand the tool's basic function. It lacks explicit mention of overwriting behavior or response format, but these are not critical given the schema and annotations. Slight improvement could clarify how values are applied to the ranges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters (spreadsheetId, data, valueInputOption). The description does not add extra meaning beyond what the schema already documents, maintaining the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('update') and resource ('values in multiple ranges of a Google Sheets spreadsheet'). It distinguishes from sibling tools like sheets_update_values by explicitly mentioning 'multiple ranges', making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear context (batch update of multiple ranges) but does not explicitly state when to use this tool over alternatives, nor does it mention exclusion criteria or specific scenarios. The guidance is implied by the wording and not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds the specific scope of returned data but does not disclose edge-case behaviors, error conditions, or system side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence that lists all returned elements without redundant phrases. It earns its place and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the returned dimension data, which gives the agent a solid understanding of the tool's output. It does not specify the exact return format (e.g., arrays vs objects), but for this read-only tool with simple params, the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (spreadsheetId, sheetName) are fully described in the input schema with 100% coverage. The description repeats no parameter details and adds no additional parameter-specific meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('sheet dimensions') and enumerates the exact data returned (column widths, row heights, hidden rows/columns, frozen counts), clearly distinguishing it from sibling tools like get_sheet_structure or get_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need dimension info), but it does not name alternatives or specify when not to use it. No explicit guidance on choosing between this and similar tools like sheets_get_sheet_structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds no further behavioral details (e.g., behavior on duplicate titles or side effects). It does not contradict the annotations, but it also does not enrich the agent's understanding beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that states the core purpose without superfluous words. It is front-loaded with the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema and annotations, the description provides sufficient context for a simple add-sheet operation. However, it does not mention optional parameters' effects or expected return value, though the schema partially covers this. It is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are fully described in the schema (100% coverage), so the baseline applies. The description does not add extra meaning to the parameters, such as how index or rowCount affect the sheet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add), the object (a new sheet), and the scope (existing spreadsheet), distinguishing it from creating a new spreadsheet. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (adding a sheet to an existing spreadsheet) but does not explicitly mention alternatives or when not to use this tool. It lacks exclusions or comparative guidance against sibling tools like sheets_create_spreadsheet or sheets_duplicate_sheet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint and destructiveHint, covering the safety profile. The description adds no further behavioral context, such as whether only specified properties are updated (partial update) or how the API responds. It doesn't contradict annotations, but also doesn't disclose the patch semantics, which is useful for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and to the point, though it could have included slightly more context without becoming verbose. Every word is necessary, but it's minimal in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (including nested objects) and no output schema, the description is quite thin. It doesn't explain the partial-update behavior or what the API returns. However, with comprehensive schema descriptions and annotations, the agent can still use it correctly for basic property updates, but important behavioral gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (spreadsheetId, sheetId, title, tabColor, gridProperties) has its own description. The tool description does not add additional meaning beyond the schema, so the baseline of 3 applies since the schema already provides the necessary semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update properties of a sheet in a Google Sheets spreadsheet' clearly states the action (update) and the resource (sheet properties), distinguishing it from sibling tools that update values, format cells, or manage charts. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to modify sheet-level properties (title, tab color, grid properties) in a spreadsheet. While it doesn't explicitly rule out alternatives, the operation is unique among siblings (there is no other 'update properties' tool), so the usage context is clear enough without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive action (deleting sheets) but adds no further context about irreversibility, error handling, or partial failures. The idempotentHint annotation provides some behavioral cue, but the description itself does not go beyond stating the obvious resource affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple batch-delete operation with only two parameters and no output schema, the description is sufficiently complete. It tells the agent what the tool does, and the schema fills in parameter details. The lack of a return-value explanation is not a concern given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the tool description does not need to add much. It adds no additional meaning beyond what the schema already provides, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (multiple sheets in a spreadsheet), and the batch nature ('in a single operation'). This distinguishes it from the sibling tool sheets_delete_sheet, which handles single-sheet deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a single operation' provides clear context for when to use this tool (when deleting multiple sheets at once). However, it does not explicitly mention the alternative for single-sheet deletion or any exclusions, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description 'Copy a sheet' adds minimal behavioral context beyond the tool name; it does not explain side effects like whether a new sheet is created in the destination or whether formatting/formulas carry over. However, given the annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. It contains no filler, repetition, or unnecessary details, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with full schema descriptions and safety annotations, the description is nearly complete. It clearly communicates the cross-spreadsheet nature of the operation. It lacks explicit return-value info, but the absence of an output schema makes that less critical. The main gap is not mentioning prerequisites like access permissions to both spreadsheets, but that is not essential for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers all three parameters with descriptions of sheetId, spreadsheetId, and destinationSpreadsheetId (100% coverage). The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy') and the resource ('a sheet') with a specific destination ('another Google Sheets spreadsheet'). This distinguishes it from siblings like sheets_duplicate_sheet, which likely copies within the same spreadsheet, and sheets_insert_sheet, which creates a blank sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case: copying a sheet across spreadsheets. While it does not explicitly exclude alternatives or name a sibling tool, the phrase 'another Google Sheets spreadsheet' provides clear context for when this tool is the right choice over in-spreadsheet duplication tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds useful behavioral detail by specifying exactly what data is returned and the sentinel behavior 'Returns hasBasicFilter: false if no filter is applied,' which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that packages the verb, target, key data components, and a useful edge-case return value. Every phrase earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of explaining return contents, and it does so for the main use case (filter config and hasBasicFilter flag). It is complete enough for a read-only, two-parameter tool, though it could mention behavior for invalid sheet names or permissions, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions for spreadsheetId and sheetName, so the baseline is 3. The description does not add meaningful parameter details, but it does not need to since the schema is complete and unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Read the Basic Filter (AutoFilter) configuration for a sheet,' which clearly identifies the tool's function. It also lists concrete components (filtered range, sort specs, per-column criteria) and distinguishes it from sibling tools that handle other sheet aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need AutoFilter configuration) but does not explicitly contrast it with alternatives like sheets_get_full_sheet_snapshot or sheets_get_sheet_structure. No 'when not to use' or exclusionary guidance is provided, so it is adequate but not strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering safety and repeatability. The description adds behavioral context about automatic detection and locale support, but does not disclose what happens to existing cell contents or how formatting is applied. This adds some value beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and key differentiators. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description plus rich schema provides adequate context for basic use. It does not clarify multi-cell range behavior or return values, but the tool's purpose is simple and the schema covers all parameters. Given moderate complexity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (date, range, format, autoDetect, useEUFormat, spreadsheetId) are documented. The description's mention of 'locale support' and 'automatic detection' loosely aligns with format and autoDetect params, but it adds no new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Insert properly formatted dates in Google Sheets' with specific features like locale support and automatic detection. This verb+resource+feature structure distinguishes it from sibling tools like sheets_update_values or sheets_format_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the tool's niche—handling date insertion with locale awareness—but does not explicitly name alternative tools or when not to use them. The context is clear enough for an agent to select it for date-specific tasks, though it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, which cover the safety profile. The description adds that it returns information about allowed operations, but does not disclose any nuances like required auth roles or edge cases. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states both the action and the return value. It is front-loaded, concise, and contains no irrelevant information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description fully conveys the tool's purpose and return value. It explains what the tool does and what information it returns, which is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already well-documented. The tool description does not add extra meaning beyond the schema, but with full coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking access permissions for a spreadsheet. It uses a specific verb ('check') and resource ('access permissions'), and this distinguishes it from all sibling tools, none of which are about access control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need to verify access permissions for a spreadsheet. It does not explicitly name alternatives or exclusions, but given no other sibling tool provides this functionality, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds substantial behavioral context: it returns a 'compact list of unique validation rules grouped by their cell ranges (run-length encoded)' and enumerates the validation categories it can detect. This goes beyond the annotations by explaining the return format and grouping logic, making the tool's behavior transparent. It doesn't cover error cases or pagination, but for a read-only tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, then the return format, then the use cases. Every sentence adds distinct value: the first states what it does, the second explains output structure and applicability. There is no redundancy or filler, so it earns a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 params, no output schema), the description adequately explains what the tool returns (compact list, run-length encoded, grouped by ranges) and why it's useful. It names the validation types it detects, providing a clear mental model. It doesn't provide an example output structure or edge cases, but for a read-only tool with stable annotations and a clear return description, this is complete enough for an agent to select and invoke correctly. Sibling tools don't overlap, so no context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (range, sheetName, spreadsheetId) clearly described in the schema. The description adds no extra parameter semantics beyond what the schema provides; it mentions 'sheet or range' but doesn't elaborate on parameter syntax or constraints. Since the schema already does the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' with a clear resource 'data validation rules' and scope 'from a sheet or range.' It distinguishes itself from sibling tools by naming specific validation types (checkboxes, dropdown lists), which no other sibling tool covers. This makes the tool's unique purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is 'Useful for discovering checkboxes (BOOLEAN), dropdown lists (ONE_OF_LIST / ONE_OF_RANGE), number constraints, and custom formula validations,' providing clear context for when to use. It doesn't explicitly state when not to use it or name alternatives, but the use cases are concrete enough to guide selection. No exclusions are mentioned, so this is a clear context without full alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds value by disclosing the return shape (2D array) and the distinction between effective and user-entered format, which are behavioral details not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly worded sentences. The first sentence front-loads the purpose and lists attributes, the second explains the return array and a key parameter tip. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only formatting getter with good annotations and a simple parameter set, the description sufficiently covers the return format and the effective-format option. It could mention edge cases like empty cells, but given the tool's scope, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters (100% coverage), so the baseline is 3. The description adds a list of formatting attributes and return behavior, but this is more about output than parameter syntax or semantics, so it does not significantly elevate the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and clearly identifies the resource as 'cell formatting for a range,' listing attributes like background color, font, and alignment. This distinguishes it from siblings like sheets_get_values (which reads values) and sheets_get_formatting_compact (which likely returns a compact view).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context for when to use the tool (when formatting is needed) and gives a specific guideline for the useEffectiveFormat parameter. It does not explicitly compare to alternative tools, but the purpose is unambiguous enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context beyond these: row-count matching for fixed ranges, auto-expansion for flexible ranges, and the warning that empty rows in the data array still count as rows. This is significant practical information that annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: one clear purpose sentence followed by three bullet-point examples and a critical warning. Every sentence earns its place, with no redundancy or filler. The structure makes the content easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the most critical usage nuances (fixed vs flexible ranges, row-count rules) that are not obvious from the schema or annotations. It does not mention return values, but the absence of an output schema and the mutation nature make that less essential. Overall, it gives an agent enough context to use the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description enhances the parameter understanding with concrete examples for the 'range' parameter, such as avoiding 'A42:E53' and using 'A42' to prevent row-count mismatch errors. This goes beyond the schema's formal definition and gives the agent actionable guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update values in a specified range of a Google Sheets spreadsheet.' The examples further clarify the exact behavior (fixed vs flexible ranges) and distinguish it from append/clear/read tools by focusing on overwriting existing cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed usage examples and tips (e.g., using 'A42' for rows 42-74) but does not explicitly contrast with sibling tools like sheets_batch_update_values or sheets_append_values. When to choose this tool is implied rather than directly stated, leaving the agent to infer the differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds valuable context about the output format (horizontal and vertical grids), the style detail controlled by includeStyle, and the larger output size. This goes beyond the annotations and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and every sentence adds value (output format, ambiguity solving, option effects). No wasted words or redundancy with schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with no output schema, the description sufficiently explains what is returned (two 2D arrays), the meaning of the grids, and the effect of includeStyle. It also clarifies the range requirement indirectly via the schema. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds only marginal detail (e.g., 'larger output' for includeStyle), which is not essential given the schema. Baseline of 3 is appropriate because the schema shoulders the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns a visual tabular map of borders for a range.' It also explains the compact grid format and the ambiguity it resolves, which distinguishes it from generic border getters. The verb 'returns' and resource 'borders for a range' make the purpose precise and differentiate it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong context by explaining that it overcomes the right/left border ambiguity and offers a compact alternative to per-cell JSON. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions or named alternatives needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds the return format (A1 notation and GridRange coordinates), which is useful beyond the annotations. It does not discuss errors or empty results, but the safety profile is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence that states the operation and result format. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, high schema coverage, and read-only annotations, the description fully covers the tool's purpose, scope, and return format. No output schema exists, but the return format disclosure is sufficient for this simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (spreadsheetId and sheetName), with clear descriptions. The tool description does not add extra parameter-specific meaning, but the schema already provides sufficient semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'merged cell ranges' with scope 'for a specific sheet'. It unambiguously distinguishes from sibling tools like sheets_merge_cells (action) and sheets_unmerge_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: to retrieve all merged ranges from a sheet. It does not explicitly mention alternatives or exclusions, but the purpose is clear enough that an agent can infer when to use it. The readOnlyHint annotation reinforces it as a safe inspection tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the critical default behavior that existing empty cells will be overwritten, which adds meaningful context beyond the destructiveHint=false annotation. It also offers a clear remediation path (INSERT_ROWS). It does not mention authentication, return values, or effects on non-empty cells, but the key risk is addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The important warning about overwriting is front-loaded and immediately actionable, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 5 parameters, nested values array, and lack of output schema, the description covers the most consequential behavioral nuance (insert vs overwrite) while the schema handles parameter details. It could mention return values or explicitly compare with sheets_update_values, but it is largely sufficient for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 5 parameters with 100% coverage, so the baseline is 3. The description adds value by explaining the practical implication of the insertDataOption enum (OVERWRITE vs INSERT_ROWS) and its default, which the schema alone does not convey. It does not add detail for values or range, but those are already well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific action ('Append values to the end of a table') and the resource ('Google Sheets spreadsheet'), which distinguishes it from update, clear, and insert-related sibling tools. The mention of 'end of a table' makes the scope precise and differentiates it from other write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that this tool is for appending to a table and explicitly tells the user how to choose between overwriting empty cells and inserting new rows via insertDataOption. However, it does not explicitly name alternative sibling tools or give a when-not-to-use statement, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds significant extra detail: normalized formulas to English locale, inclusion of '_formulaLocaleRaw', and the option to disable normalization. This goes beyond annotations and explains important behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and then a focused note on normalization. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only getter with no output schema, the description covers what is read (CF rules, banded ranges), default normalization, the raw locale field, and the escape hatch via parameter. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description reinforces the normalization behavior already in the schema but doesn't add new meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads conditional formatting rules and banded ranges, using a specific verb (Read) and resource. It distinguishes from siblings like 'sheet_get_sheet_formatting' by focusing on conditional formatting specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this tool is for reading conditional formatting and banded ranges, and mentions the normalization behavior. Though it doesn't explicitly name alternatives, the scope is well-defined so an agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses the diff output format, positional comparison semantics, the equal-dimension requirement, and the default behavior when 'fields' is omitted. This provides a clear model of tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, each adding substantive information: purpose, examples, output, dimension constraint, and fields guidance. It is front-loaded and contains no fluff or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete schema and readOnly/idempotent annotations, the description fills remaining gaps: it explains the return format (diff), comparison semantics, and the dimension constraint. The tool's behavior is fully covered for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, so the baseline is 3. The description adds value with a concrete example for 'fields' and clarifies that rangeA/rangeB must have matching dimensions, supplementing the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope ('Compare cell formatting between two ranges of identical dimensions') and provides concrete example use cases. It clearly distinguishes this tool from sibling sheet tools by focusing solely on formatting comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context with examples ('do all data rows 6–85 have identical formatting?') and mentions the 'fields' parameter to restrict comparison. However, it does not explicitly state when not to use the tool or name alternatives, though no sibling tool performs the same function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, but the description goes far beyond by exposing defaults (compactMode OFF, includeConditionalFormatting true), output size implications of compactMode, and the locale normalization of CF formulas. This adds substantial behavioral context not available from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it starts with the overall purpose, lists return contents, then explains each option and its default. Every sentence contributes meaningful information without redundant filler, achieving high information density in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly enumerates what is returned (sheet properties, merged cells, widths, heights, banded ranges, optional formatting) and covers all major behaviors (compact mode, conditional formatting, field filtering, locale normalization). For a tool with 7 parameters and no output schema, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of fields limit, the effect of compactMode on output size, and the conditional formatting default, which complements but does not merely repeat schema descriptions. It slightly exceeds the baseline by clarifying parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reads') and resource ('all structural and formatting metadata for a sheet'), clearly distinguishing it from siblings like sheets_get_sheet_structure or sheets_get_sheet_formatting. It also explicitly frames it as a 'one-shot' comprehensive snapshot, which differentiates its scope from lighter getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context and a primary use case: 'Use this before programmatically recreating a sheet.' It also explains when to enable compactMode or includeConditionalFormatting, but does not explicitly name alternative lighter tools or state when not to use this tool, falling just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint and idempotentHint, and the description adds valuable behavioral context beyond that: it explicitly states 'no per-cell data', lists all types of metadata returned, and reveals implementation traits like 'single API call with minimal field mask' and 'much faster and cheaper'. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it front-loads the primary purpose, follows with a detailed list of what is returned, then closes with usage guidance and performance context. All sentences contribute meaningful information without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is remarkably complete. It specifies return values, usage context, performance characteristics, and explicitly states what it does NOT return (per-cell data). This fully compensates for the absence of an output schema and covers the tool's complexity well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are fully described in the schema. The description does not add additional semantics for parameters, but per the rubric, the high schema coverage means the baseline is 3 and the description is not required to repeat parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning ONLY structural/dimensional metadata for a sheet, and it lists the specific metadata items returned. It also distinguishes itself from a sibling tool (sheets_get_full_sheet_snapshot) by explicitly noting it excludes per-cell data, making it highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this instead of sheets_get_full_sheet_snapshot when per-cell formatting is not needed.' It also highlights performance benefits ('Much faster and cheaper'), giving the agent clear criteria for selecting this tool over an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses the output compression behavior (collapsing adjacent identical cells, 90%+ size reduction) and the supported format fields. This adds meaningful behavioral context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: first sentence states purpose and output, second explains run-length encoding, third gives usage guidance, and fourth lists supported fields. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description adequately explains the return format (A1Range→format pairs with run-length encoding) and supported fields. It doesn't detail the exact JSON structure, but for a read-only formatting retrieval tool, this is sufficient. Slightly more detail on the pair structure could improve completeness, but it's already strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds value by explicitly listing the allowed values for the 'fields' parameter (e.g., backgroundColor, textFormat), which supplements the schema's generic description. It also clarifies the compact output relates to parameter choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns cell formatting as compact A1Range→format pairs, using run-length encoding. It distinguishes from sibling tools by recommending it over sheets_get_full_sheet_snapshot for formatting-only needs and lists supported fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use instead of sheets_get_full_sheet_snapshot when you only need formatting data.' This clearly indicates a use case and names an alternative, helping the agent select the right tool among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/freema/mcp-gsheets'
If you have feedback or need assistance with the MCP directory API, please join our Discord server