Google Sheets MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct operation: sheet management, cell reads/writes, row/column modifications, formatting, charts, sorting, find/replace, and sharing. Even similar tools like read_cells vs batch_read and write_cells vs batch_write are clearly separated by single vs. multi-range scope, and descriptions clarify the boundaries.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., create_sheet, delete_sheet, read_cells, format_cells, list_charts). No camelCase or mismatched conventions are present, and verbs are consistently placed first.
Tool Count2/5
With 27 tools, the set exceeds the 25-tool threshold for 'heavy' servers. While each tool has a clear purpose, the count feels excessive for typical spreadsheet interactions; some batch and formatting operations could be consolidated without losing functionality.
Completeness3/5
Core spreadsheet and sheet lifecycle operations are well covered (create, read, list, rename, duplicate, delete sheets; read/write cells; row/column manipulation; charts; sharing). However, there is no tool to delete a spreadsheet or rename the spreadsheet itself, which are notable gaps in full lifecycle management.
Average 4/5 across 27 of 27 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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?
No annotations are provided, so the description must disclose behavioral traits. It only lists parameters and a success message, without mentioning that this is a mutating operation that overwrites existing widths, requires write permissions, or could affect layout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by a clear Args list and a Returns line. Every section serves a purpose, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the operation and parameter semantics, and the output schema handles return values. However, it lacks usage guidance and side-effect disclosure, making it adequate but incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description fully explains each parameter, including 0-based column indexing, exclusive end, pixel units, and the distinction between spreadsheet and sheet IDs. This entirely compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set the width of columns') with a specific verb and resource. It doesn't explicitly differentiate from sibling tools like format_cells, but the name and description are 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/5
Does 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 format_cells or insert_columns. There is no mention of context, prerequisites, 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?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention that deleting columns is destructive, permanently removes data, and likely shifts remaining columns. It only states the action and success message, leaving the agent unaware of consequences and potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an Args section and Returns section. Every sentence provides necessary information, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's basic function and parameters, but it lacks important context about side effects (e.g., data loss, column shifts), error conditions, and prerequisites. Given that this is a destructive operation and annotations are absent, more completeness would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description compensates by explaining each parameter: spreadsheet_id, sheet_id, 0-based start_index, and num_columns. This adds meaning beyond the raw schema, particularly clarifying the indexing convention and that num_columns is a count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete columns from a sheet' uses a specific verb (delete) and resource (columns), clearly distinguishing it from sibling tools like delete_rows and delete_sheet. The intended action is 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/5
Does 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. It does not mention that this is for removing columns, nor does it contrast with delete_rows or insert_columns. There is no context to help an agent decide between similar operations.
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?
No annotations are provided, and the description does not disclose behavioral traits such as potential side effects (e.g., breaking references), failure conditions, or permission requirements. It only notes the return value as a success message.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-liner summary followed by an Args section and Returns note. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename operation, the description covers basic usage and return values, but omits edge cases such as duplicate title validation, handling of non-existent sheets, or impacts on formulas/references. With a valid output schema, it is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema description coverage by explaining each parameter: spreadsheet_id, sheet_id (noting it is numeric), and new_title. This adds meaning beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a sheet' clearly states the action and resource, distinguishing it from sibling tools like create_sheet and duplicate_sheet. It is 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 Guidelines2/5
Does 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, nor does it mention any prerequisites or exclusions. It simply states the function without contextual cues.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions delete action and success message but fails to note that deletions are permanent, rows shift, or any side effects such as affecting formulas. The 0-based indexing is clarified, but the irreversible nature and potential cascading effects are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a model of conciseness. The purpose leads in one sentence, then a structured Args block with clear labels, and a Returns line. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the parameters and return value, which is adequate for a straightforward deletion tool. However, given the lack of annotations and usage guidance, the absence of behavioral context (e.g., permanence, index shifting, error handling) leaves the tool incomplete for an agent that needs to anticipate consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has no descriptions for its parameters (0% coverage), the tool description compensates well by explicitly defining each parameter: spreadsheet_id, sheet_id, start_index (0-based), and num_rows. This adds meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete rows from a sheet', which is a specific verb+resource. It completely distinguishes this tool from siblings like insert_rows, append_rows, and clear_cells by naming the exact operation and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting rows but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. It gives parameter instructions but no context about prerequisites or situations where a different tool would be more appropriate.
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 no annotations, the description carries the burden. It discloses the return shape (JSON with metadata, sheets list, URL) and that the parameter is from the URL, but does not elaborate on safety or potential errors. Since it is a read operation, the name implies non-destructive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main sentence front-loaded, followed by clearly labeled Args and Returns sections. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and an output schema available, the description is sufficient. It explains the return contents even though the output schema might already provide this, and it gives the key input context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section explains spreadsheet_id as 'The ID of the spreadsheet (from URL)', adding meaning beyond the raw schema. This adequately compensates for the single parameter's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets information about a spreadsheet including all sheets, using a specific verb and resource. It does not explicitly differentiate from siblings like list_sheets, but the scope is broader, mentioning metadata and URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied from the purpose: the agent would call this when it needs spreadsheet-level metadata and sheet list. However, there is no explicit guidance about when to use this instead of more specific tools like list_sheets.
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?
No annotations are provided, so the description carries the full burden. It discloses the return format (JSON list with IDs, titles, positions) but does not mention any behavioral limitations such as whether hidden charts are included or if it operates across all sheets. 'List' implies read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear Args and Returns sections. Every sentence is purposeful and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description covers the primary input and output adequately. It could mention whether charts are listed across all sheets or only one sheet, but given the simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'spreadsheet_id' with title 'Spreadsheet Id'. The description says 'The ID of the spreadsheet', which adds almost no new meaning beyond the schema title. With 0% schema description coverage, the description should provide richer compensation, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'List' with a clear resource 'all charts in a spreadsheet', which distinguishes it from sibling tools like create_chart, delete_chart, and list_sheets. The scope is unambiguous and matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need chart IDs, titles, or positions) but does not explicitly state when not to use it or mention alternatives. For a simple tool this is acceptable but not proactive guidance.
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?
No annotations are provided, so the description must disclose behavioral traits. It mentions formula support and returns, but does not disclose side effects like overwriting existing cell values or what happens if the provided array is smaller than the range. This is a significant gap for a write 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short summary, practical examples, a clear Args section, and a Returns note. Every sentence and example adds value, making it concise despite its moderate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, provides return value information, and includes realistic usage examples. However, it lacks guidance on when to use the tool versus siblings and omits side-effect behavior, leaving minor ambiguity for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section provides full detail for all three parameters beyond the schema: spreadsheet_id as 'The ID from the spreadsheet URL', range_notation as 'Starting cell in A1 notation', and values as 'JSON 2D array' with formula examples. This fully compensates for the schema's 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Write values to cells.' It provides multiple examples showing the expected input format and distinguishes itself from sibling tools like read_cells and clear_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as batch_write, append_rows, or clear_cells. The examples demonstrate invocation but do not outline selection criteria 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?
No annotations are provided, so the description must carry the full disclosure burden. However, it only lists parameters and states a success return. It does not disclose that merging cells may overwrite existing data, is irreversible, or requires specific permissions. This is a basic operational description without behavioral caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections. It front-loads the purpose and then systematically defines each argument. The 'Returns: Success message' is a slight redundancy given the output schema, but it is concise and not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and an output schema, the description covers the operation and all parameter details effectively. It lacks behavioral context like side effects or permission requirements (which lowers this score), but it is otherwise adequate for an agent to understand what arguments to pass and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage (only titles), but the description fully explains every parameter: spreadsheet_id, sheet_id, row/column indices (including 0-based and exclusive end values), and merge_type options. This is exactly the semantic richness needed for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Merge cells in a range.' which is a specific verb+resource statement, clearly distinguishing this operation from sibling tools like write_cells or format_cells. It is not a tautology and immediately tells the agent 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to merge cells in a spreadsheet) but provides no explicit guidance on when to use this tool versus alternatives like format_cells or sort_range. There are no exclusions or prerequisites mentioned, so it only meets the 'implied usage' level.
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?
Since no annotations are provided, the description must fully disclose behavioral traits. It states the action and return message but omits whether the deletion is permanent, irreversible, or requires special permissions. The verb 'Delete' signals destructiveness, but the lack of any caution or side-effect disclosure is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a one-sentence purpose, an Args section, and a Returns section. Every sentence provides necessary information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter deletion tool, the description adequately covers the action, parameters, and return value, and the output schema can fill in the response structure. The main omission is explicit mention of irreversibility or side effects, which is relevant for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It compensates well by explaining spreadsheet_id as the spreadsheet ID and sheet_id as the numeric sheet ID from list_sheets, adding valuable context beyond the bare schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a sheet from a spreadsheet,' which clearly states a specific verb and resource. This distinguishes it from sibling tools like delete_rows and delete_columns, which operate on 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that sheet_id comes from list_sheets, which is a useful prerequisite. However, it does not explicitly state when to use this tool versus alternatives such as delete_rows or duplicate_sheet, leaving usage context implied rather than fully specified.
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?
No annotations are provided, so the description carries the full burden. It discloses the return format (JSON with new sheet's ID, title, and index) and the 'within the same spreadsheet' scope, but it does not mention that the original sheet remains unchanged, whether formatting or formulas are copied, or any permission requirements. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one purpose statement, an Args list, and a Returns line. There is no fluff, and the structure is clear and front-loaded. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and an output schema, the description covers purpose, all arguments, and return values. It lacks usage guidance and behavioral details like side effects, but these are partially covered under other dimensions. Overall, it is a fairly complete description for a simple duplication operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only titles (e.g., 'Sheet Id') with no descriptions. The description compensates by explicitly listing each argument and giving a concise explanation, including the default behavior of insert_index (-1 for end). This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Duplicate/copy') plus a resource ('a sheet') and a scope ('within the same spreadsheet'), clearly distinguishing it from sibling tools like create_sheet or rename_sheet. It is immediately obvious 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that this is for copying an existing sheet as opposed to creating a new one, nor does it provide any exclusions or prerequisites. The description is purely functional without contextual usage advice.
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 no annotations, the description must carry safety and behavior info. It discloses the return format (JSON with 1-based row number) but does not specify behavior with blank cells, empty columns, or whether it scans the entire column or stops at the first blank. This ambiguity may mislead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured with Args and Returns sections. No superfluous information, and the default column value is included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the core purpose and args are covered. However, edge-case behavior around empty cells is not addressed, which is relevant given the tool's core function. The output schema existence reduces need to detail return values, but the behavioral gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the only source of parameter semantics. It explains each parameter, including the column letter default 'A', which adds value beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and object: 'Find the last row with data in a column.' This specifies the action and resource, distinguishing it from sibling read tools like read_cells and batch_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies its use case, but does not mention exclusions or sibling tools.
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 core behavior (inserting empty columns) but does not mention side effects like shifting existing columns to the right or any permission requirements. Since no annotations are provided, the description carries the burden but is still somewhat 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args and Returns sections. It provides necessary information in a compact format without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple spreadsheet mutation, the description covers the operation and all parameters. However, it omits any mention of side effects or safety considerations, making it somewhat incomplete despite the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds detailed semantic meaning for all four parameters, including an explicit 0-based index explanation for start_index. Schema coverage is 0%, so this is essential and well-executed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Insert empty columns at a specific position' with a specific resource. It distinguishes from sibling tools like insert_rows or delete_columns by its column-specific focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 insert_rows or append_rows. The description is purely operational and lacks any exclusions or context about appropriate use cases.
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 no annotations, the description carries the burden of behavioral disclosure. It adds useful context about 0-based indexing, exclusive end row/column, and ascending semantics, but does not explicitly mention that sorting is an in-place mutation, potential data loss, or any permission requirements. This is a moderate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured as a docstring with Args and Returns sections. Each line serves a purpose, and the length is appropriate for the number of parameters. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and no schema description coverage, the description provides all parameter semantics and a return value indicator. It lacks usage context and side-effect warnings, but for a sorting operation with clear parameter explanations, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter in the Args section. It clarifies that sort_column is relative to the range, specifies 0-based indices, explains exclusive end bounds, and defines ascending behavior. This is excellent semantic coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Sort data in a range by a column' with a specific verb and resource. It is distinct from sibling tools, none of which focus on sorting, making the purpose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely specifies the operation and parameters, leaving the usage context to be inferred from the title and description.
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?
No annotations are provided, so description carries burden. It states the mutation (append) and describes return format (JSON with updated range and appended cells), but does not disclose permissions, side effects on existing data, or behavior with empty ranges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus compact Args/Returns list; front-loaded with the core purpose. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-param append tool with an output schema, it covers purpose, each parameter, and return format. Lacks explicit usage guidance versus sibling tools and edge-case behavior, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero descriptions for all three parameters, and the description compensates fully by explaining each parameter's meaning: spreadsheet ID, A1 range notation, and JSON 2D array of rows. Includes example for range_notation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Append' and resource 'rows to the end of data in a sheet', clearly distinguishing from insert_rows and write_cells by specifying end-of-sheet behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies appending to end-of-sheet but does not explicitly state when to choose this over insert_rows or write_cells. It provides clear context (appending) but no exclusions or alternative comparisons.
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 no annotations, the description carries the full burden. It discloses the return format (JSON with ID, title, index) and explains the index default, but it does not explicitly mention side effects (e.g., that it modifies the spreadsheet) or any permissions/error behavior. Since 'create' implies a write operation, the omission of explicit mutation is notable but not severely misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a clear 'Args' section with each parameter, and a 'Returns' section. Every sentence earns its place; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with 3 parameters, the description covers the essential elements: what the tool does, the arguments, and the return value. It doesn't mention error cases (e.g., duplicate title) or permissions, but given the simplicity and the fact that the return value is described, it is largely complete. The lack of annotations slightly reduces transparency, but not enough to penalize heavily.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly: spreadsheet_id is defined as 'The ID of the spreadsheet,' title as 'Name for the new sheet,' and index as 'Position for the new sheet (-1 for end),' which also explains the default behavior. This adds clear meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a new sheet/tab in a spreadsheet,' which uses a specific verb and resource, clearly distinguishing it from sibling tools like create_spreadsheet (creates a whole spreadsheet) and duplicate_sheet (copies an existing sheet). The rest of the description reinforces this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The usage is implied (you need an existing spreadsheet), but there is no direct guidance about when to prefer create_sheet over, say, create_spreadsheet or rename_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?
No annotations exist, so the description carries the burden. It clearly states the creation action and the return payload, but does not disclose permissions, potential side effects beyond creation, or behavior when title already exists. The 'new' keyword implies a fresh resource, but no details on authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a one-sentence summary, an Args list, and a Returns line. No redundant phrases or filler, achieving a good front-loaded structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with two parameters and an output schema, the description covers inputs and outputs adequately. However, it does not provide context about how sheet_names interacts with the default sheet, nor does it mention any prerequisites or alternatives, leaving a slight gap given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are explained in the Args section: title is described as 'The title for the new spreadsheet' and sheet_names as 'Comma-separated list of sheet names (optional),' fully compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new Google Spreadsheet' with a specific verb and resource, clearly distinguishing from sibling create_sheet which adds a sheet to an existing 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, though the name implies creating a new file. The description does not mention create_sheet as an alternative for adding sheets to an existing spreadsheet, leaving the differentiation implied.
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 no annotations, the description carries the burden of conveying behavior. It mentions the return format and 'all sheets' scope, but does not explicitly state that the operation is read-only or has no side effects. The verb 'List' strongly implies safe reading, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured with a one-sentence summary followed by Args and Returns sections. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation with an output schema, the description covers purpose, parameter, and return value adequately. There are no hidden complexities or side effects that need further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for spreadsheet_id, but the tool description adds a clear definition ('The ID of the spreadsheet'). This fills the schema coverage gap and provides essential meaning for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List all sheets/tabs in a spreadsheet'). It is distinct from sibling tools like get_spreadsheet_info, which focuses on spreadsheet metadata, and other sheet 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/5
Does 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 to enumerate sheets) but does not explicitly compare to alternatives or mention exclusions. There is no 'use X instead' guidance, so usage context is inferred rather than stated.
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 no annotations, the description carries the burden of disclosure. It states the return format (JSON object mapping ranges to values) and input requirements, but does not mention error behavior, authentication, or explicit read-only nature beyond the word 'read.' This is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured into Args and Returns, and the purpose statement is front-loaded. Every sentence provides necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no nested objects), and an output schema exists (per context). The description covers purpose, parameters, and return format sufficiently for a read-only batch operation. No additional details are needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does so thoroughly: 'spreadsheet_id' is identified, and 'ranges' is explained with a concrete example ('Sheet1!A1:B5,Sheet1!D1:E5'). This fully compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action: 'Read values from multiple ranges at once.' It uses a verb ('read') and a resource ('values from multiple ranges'), and the phrase 'at once' distinguishes it from single-range reads like read_cells and from batch_write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading multiple ranges but does not explicitly state when to prefer this over alternatives (e.g., read_cells for single ranges) or provide exclusions. No guidance on when not to use it 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?
No annotations are present, so the description bears the full burden. It states the action and that a success message is returned, but it does not disclose permanence, permission requirements, or behavior if the chart does not exist. This adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is stated in the first sentence, followed by a clean Args/Returns structure. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation, the description covers the essential inputs and return type. The existence of an output schema further specifies the result, but the description could mention error scenarios (e.g., nonexistent chart) without being overly verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters with one-line descriptions, and explicitly links chart_id to list_charts, providing context for sourcing the value. Since the schema has zero per-parameter descriptions, this compensation is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a chart from the spreadsheet, using a specific verb and resource. It distinguishes itself from sibling tools like create_chart and list_charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It notes that chart_id comes from list_charts, which implies a prerequisite and helps the agent know how to obtain the correct value. However, it does not explicitly state when to use this tool versus alternatives or when not 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?
No annotations are provided, so the description carries the transparency burden. It does disclose crucial behavioral details: 0-based indexing, exclusive end row/column, and the return of a success message. However, it does not mention whether formatting is additive or overwrites existing formatting, or any permission requirements. It covers key behaviors but not all potential 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose sentence, illustrative examples, critical indexing notes, and an Args list. Each part serves a purpose—no filler content. The most important information (0-based indexing, exclusive bounds) is highlighted separately, and the length is justified by 12 parameters needing explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, no schema descriptions, no annotations), the description is complete. It covers all parameters, provides usage examples, explains indexing conventions, and states the return value. It also references how to obtain sheet_id, covering prerequisites. This is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage (0%), so the description must explain every parameter. It does this thoroughly with an Args section that defines each parameter, including examples and valid values (e.g., alignment 'LEFT'/'CENTER'/'RIGHT', color hex format). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource statement: 'Apply formatting to a range of cells.' It includes concrete examples that show the various formatting options (bold, background, alignment), making the purpose unmistakable and distinct from sibling tools like write_cells or clear_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by showcasing formatting scenarios, but it does not explicitly state when to prefer this tool over alternatives (e.g., 'Use this for styling, not for writing data'). Given the presence of many sibling tools, explicit exclusions or alternative references would strengthen guidance. The examples provide context, so it is not entirely missing.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions that 'Empty cells may be omitted' and specifies the return format as a JSON 2D array, which are useful behavioral details. It does not cover error conditions, but for a read operation this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-sentence summary, then examples, args, and returns. Each section adds value without redundancy, and the information is front-loaded in the first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description covers operation, parameters, usage examples, and return format. The presence of an output schema reduces the need to detail return structure further, and the description is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and types, with zero coverage in the schema descriptions. The description compensates fully by explaining spreadsheet_id as 'The ID from the spreadsheet URL' and range_notation with A1 notation format and examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read cell values from a spreadsheet range' with a specific verb and resource, and the examples clarify the exact operation. However, it does not explicitly distinguish this tool from the sibling batch_read, which might be the multi-range alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples show how to use the tool and what range notations are valid, but there is no explicit guidance on when to choose read_cells over alternatives like batch_read or get_last_row. The context is implied rather than stated.
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?
No annotations are provided, so the description carries the full burden. It discloses the return format and explains the data structure, but it does not explicitly state that this operation overwrites existing cell values or mention any side effects, permissions, or failure behaviors. The mutation is implied by 'write' but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a purpose statement, Args section, and Returns section. It uses a clear example without excess text. Every sentence adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool, the description covers purpose, both parameters with format, and the return value. The presence of an output schema (per context) further reduces the need to describe return details. Missing are edge cases like error handling or atomicity, but the tool is simple enough that the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate fully. It does: it explains spreadsheet_id and data, includes the exact JSON structure with 'range' and 'values' keys, and provides a concrete example. This exceeds the schema's minimal type-only information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write values to multiple ranges at once' with a specific verb and resource. This distinguishes it from sibling tools like batch_read (for reading) and write_cells (likely for a single range). The purpose is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when writing to multiple ranges efficiently. It does not explicitly name alternatives or when-not-to-use, but the phrase 'at once' implies it is for batch operations, contrasting with repeated single writes. This is clear but 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?
With no annotations provided, the description carries the full burden of disclosure. It mentions the replace action, scope control, and return count, which are useful, but it does not explicitly state the destructive nature of the operation (e.g., irreversible modification) or any permission requirements. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with a clear summary, then a structured argument list, and a return statement. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, scope options, parameter semantics, and return format. An output schema exists, so return type is already structured. It omits edge-case behavior (e.g., no matches, errors), but for a find/replace tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It does this well: 'Limit to specific sheet (-1 for all sheets)' adds default behavior, 'Case-sensitive matching' and 'Only match if cell equals find text exactly' clarify semantics beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase 'Find and replace text across the spreadsheet or a specific sheet,' clearly identifying the tool's function and resource. It distinguishes this from siblings (e.g., read_cells, write_cells) by focusing on search-and-replace behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever text needs to be replaced across an entire spreadsheet or a specific sheet. It clearly states the scope options but does not explicitly mention alternatives or exclusions, which would push it to a 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?
No annotations are provided, so the description carries the full burden. It discloses the core behavior and return value, but does not mention side effects like existing rows shifting down or permission requirements. This is a gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear Args and Returns sections. Every sentence provides useful information, with no fluff. It is concise yet complete for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple insert operation, the description covers the essentials: what it does, all parameters, and the return message. It would benefit from explicitly stating that existing rows shift down, but overall it is sufficiently complete given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description compensates fully by explaining each parameter, including the critical 0-based indexing detail for start_index. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Insert empty rows at a specific position' with a specific verb and resource. It distinguishes from siblings like append_rows by emphasizing positional insertion, making the purpose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (inserting rows at a specific position), but does not explicitly mention alternatives or when not to use it. It's implied but not formally stated.
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 no annotations, the description carries the full burden. It discloses the primary actions and the return value ('JSON with sharing result'), but it does not mention side effects (e.g., modifying ACLs), permission requirements, or error conditions. The relationship between email and make_public is implied but not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an opening summary, an 'Args' bullet list, and a 'Returns' note. Every sentence earns its place—no fluff, and the most important information (purpose) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, all parameters, their conditions, and the return format. With an output schema available (per context signal), return details are complete. It lacks edge-case behavior (e.g., what happens if email is empty and make_public is False) and permission requirements, but for a simple sharing tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter in the 'Args' section, including the allowed values for 'role' and the conditional nature of 'email' (optional if make_public=True). This adds significant meaning beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Share a spreadsheet with someone or make it publicly accessible', which clearly states the verb (share), resource (spreadsheet), and two distinct modes. It is specific and distinguishes this tool from all siblings, none of which handle sharing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on the two usage modes (share with email or make public) and explains parameter relationships. However, it does not explicitly state when NOT to use this tool or mention any alternative, though no sibling tool shares this function, making the usage inherently clear.
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?
With no annotations, the description carries the full burden. It discloses the destructive nature ('Clear all values') and a key side-effect ('keeps formatting'), which is the main behavioral nuance. It does not mention permissions or irreversibility, but that is not needed for a straightforward 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured: a one-line purpose, followed by a succinct list of arguments and returns. Every sentence contributes necessary information, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple clear operation, the description covers what it does, the parameters, and the return value. Since an output schema is present, the return description is sufficient. It provides all essentials for an agent to choose and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage, so the description compensates with explicit explanations for both parameters: 'The ID of the spreadsheet' and 'A1 notation range to clear'. These add meaning beyond the bare property names, though they are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Clear') and resource ('values in a range'), with a critical qualifier ('keeps formatting') that distinguishes it from sibling tools like format_cells or delete_rows. It immediately communicates the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'keeps formatting' provides implicit usage context: use this when you need to clear values while preserving cell formatting. It does not explicitly name alternatives or exclusions, but the behavior described makes the appropriate scenario clear.
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?
With no annotations, the description carries the transparency burden. It explains behavior like series auto-detection, PIE being single-series only, and that it returns a chart_id. While it doesn't discuss permissions or reversibility, these are less critical for a creation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear headings, examples, and an args list. It front-loads the main purpose and only includes information that aids usage, though the multiple examples make it slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and missing schema descriptions, the description is exceptionally complete. It covers all parameters, return value, chart type behaviors, and multi-series scenarios, making it self-sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description includes a comprehensive 'Args' section explaining each parameter, its default, and usage context. Examples further illustrate parameter combinations, fully compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an embedded chart with MULTIPLE SERIES support, using a specific verb and resource. It distinguishes itself from sibling tools like list_charts and delete_chart by being the creation operation, and the chart type explanations further clarify its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed examples of when to use different chart types and auto-detection behavior, giving clear context for typical usage. However, it does not explicitly mention alternatives or when not to use the tool, though its distinct purpose among siblings makes this less critical.
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:

[![spreadsheet-mcp MCP server](https://glama.ai/mcp/servers/dudegladiator/spreadsheet-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dudegladiator/spreadsheet-mcp)

Score Badge

Copy to your README.md:

[![spreadsheet-mcp MCP server](https://glama.ai/mcp/servers/dudegladiator/spreadsheet-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dudegladiator/spreadsheet-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/dudegladiator/spreadsheet-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server