Google Sheets Write MCP Server

by tg-tool

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes. The only minor overlap is between update_range and batch_update_values, but their descriptions distinguish single vs. batch writes. Otherwise, each tool targets a unique aspect of sheet manipulation.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., add_sheet, delete_columns, set_cell_style). No mixing of conventions, making it easy for agents to predict tool names.
Tool Count5/5
With 18 tools, the server covers a wide range of write operations suitable for Google Sheets. The count is appropriate—neither sparse nor overwhelming.
Completeness4/5
The server provides comprehensive CRUD-like coverage for sheets and data, plus formatting, validation, protection, and filtering. Minor gaps include no tool to restore from snapshots and no move sheet operation, but these are acceptable for a write-focused server.
Average 4.2/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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?
With no annotations, the description carries full burden. It mentions 'atomic-ish' but does not clarify what that means operationally (e.g., partial failures, rollback behavior). It glosses over the force parameter's effect on cell limits and does not disclose potential side effects, error handling, 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 concise: two lines of purpose followed by a structured list of parameter explanations. Every sentence adds necessary information without redundancy. It is front-loaded with the core purpose.
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 no output schema and no annotations, the description is fairly complete. It explains the purpose, parameters, and atomic-ish behavior. However, it lacks guidance on expected return values, error codes, and when to choose this tool over siblings like update_range. A small improvement would be to mention the dry_run output format.
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 compensate. It provides detailed explanations for all five parameters in the Args section, including the structure of 'updates' (sheet, range, values) and the meaning of boolean flags (raw, dry_run, force). 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 the purpose: 'Write multiple ranges in one call (one API request, atomic-ish).' It uses a specific verb (write) and resource (multiple ranges), and the term 'atomic-ish' distinguishes it from siblings like update_range that likely handle single ranges.
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 explicit guidance on when to use this tool versus alternatives like update_range, append_rows, or clear_range. The description mentions 'atomic-ish' but does not explain when atomicity is critical or when to avoid batch updates. Given 17 sibling tools, this omission is significant.
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 the full burden of behavioral disclosure. It explains the insertion logic (before specified row, 1-indexed) and mentions parameters like inherit_before (formatting) and dry_run (testing). However, it lacks information on side effects (e.g., data shift, formula updates), required scopes, or error conditions.
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 a concise opening sentence followed by a bullet-like list of arguments. It is front-loaded with the main action. While slightly verbose in the list, each line adds necessary detail. Minor improvement could be more succinct wording for some parameters.
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?
Given 6 parameters, no output schema, and no annotations, the description covers parameter semantics thoroughly but omits return value details (except for dry_run) and fails to mention prerequisites, limits, or error handling. The tool is moderately complex, so additional context on what happens after insertion would improve completeness.
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 0% description coverage, leaving the description to fully explain parameters. The 'Args' section provides clear semantics for all six parameters: explains start_row as 1-indexed and 'BEFORE' behavior, defines count, inherit_before, and dry_run effects. This adds significant value beyond the schema's titles.
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 blank rows before the given row number', which is a specific verb and resource. It distinguishes from sibling tools like insert_columns and delete_rows by focusing on row insertion. The description also details the effect of parameters like start_row ensuring no ambiguity.
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 does not provide any guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or comparisons with sibling tools like append_rows or update_range. The agent would need to infer usage context from the parameter descriptions alone.
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 key behaviors like the 'dry_run' option and 'warning_only' mode, but does not explain side effects such as overwriting existing protection, permissions required, or whether the changes are reversible. Without annotations, more detail is needed.
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 concise, using a one-sentence summary followed by a structured bullet list of arguments. No fluff, but the bullet list could be slightly more integrated into the prose.
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 tool has no output schema, and the description does not mention what the tool returns (e.g., success status or error details). It covers parameters well but omits return value and error conditions, leaving the agent uncertain about results.
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?
Each parameter is explained with clear semantics that go beyond the schema: 'None = whole sheet' for range, 'Label shown in the Sheets UI' for description, 'Email addresses still allowed to edit' for editors. 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 clearly states the action: 'Protect a range (or the whole sheet) from editing.' It distinguishes this tool from sibling editing tools like 'update_range' or 'set_basic_filter' by focusing on protection rather than data manipulation.
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 explicit guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites or caveats, leaving the agent to infer context from the tool name alone.
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?
Given no annotations, the description partially discloses behavior: it can clear validation by passing null rule_type, and dry_run returns an execution plan. However, it does not mention permissions, destructiveness, or response for normal execution.
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 single opening line followed by a concise, well-organized bullet list of arguments with clear explanations. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although parameter details are thorough, the description omits return value (except for dry_run) and does not mention error conditions, prerequisites, or side effects. For a tool with 8 parameters and no output schema, this leaves gaps in understanding.
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?
With 0% schema description coverage, the description adds full meaning for all 8 parameters, including examples and allowed values (e.g., rule_type: ONE_OF_LIST, NUMBER_BETWEEN). This compensates entirely for the missing schema 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 uses specific verbs 'Set (or clear)' and resource 'data validation on a range', clearly distinguishing from sibling tools like clear_range or set_conditional_format.
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 explicit guidance on when to use this tool vs alternatives, nor mention of prerequisites or exclusions. The description only states what the tool does, not when to apply it.
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 destructive behavior, the dry_run safety default, and that rows are snapshotted before deletion. It also mentions the force parameter. Missing details on where snapshots go or irreversibility, but overall strong.
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?
Description is compact and front-loaded with the key point: 'Delete rows (destructive — dry_run defaults to TRUE).' Each subsequent sentence adds necessary detail without redundancy. No wasted words.
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's complexity (6 params, destructive), no annotations, and no output schema, the description covers all parameters and behavioral effects (snapshot, dry_run, force). It does not explain return values, but that is not critical. Could mention where snapshots are stored, but otherwise 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 has 0% description coverage, but the description provides detailed meaning for all six parameters, including defaults and types (e.g., '1-indexed first row', 'Full Sheets URL or bare spreadsheet ID'). This fully compensates for schema gaps.
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 'Delete rows' and the resource, and implies it is destructive. It provides specifics like snapshotting, which distinguishes it from clear_range. However, it does not explicitly differentiate from sibling tools such as delete_columns or delete_sheet, leaving some ambiguity.
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 mentions that dry_run defaults to TRUE, implying a safe preview mode, but does not provide explicit guidance on when to use this tool versus alternatives like clear_range or delete_sheet. No when-not-to-use or alternatives are listed.
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 explains key behaviors via parameters: dry_run returns a plan without changes, inherit_before copies formatting from the left column. However, it does not disclose side effects like shifting existing columns to the right or potential data loss if columns contain data. Since no annotations are provided, the description carries the full transparency burden and only partially meets it.
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 sentence for the core purpose followed by clean, bullet-like parameter descriptions. Every sentence adds value, and the structure front-loads the essential 'what it does' before details. No redundant or trivial information.
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 6 parameters, no annotations, and no output schema, the description covers all parameters and primary behavior. However, it lacks contextual information such as error handling, prerequisites (e.g., spreadsheet edit access), or a note about the resulting column shift. It also does not differentiate from sibling tools like insert_rows in terms of when to use each. Nonetheless, for a straightforward insertion operation, 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?
The input schema has 0% description coverage, so the description provides all parameter meaning. Each parameter is explained with helpful details: spreadsheet_id_or_url accepts URL or ID, sheet accepts name or gid, start_column is a letter or 1-indexed number, count is integer, inherit_before and dry_run are booleans with clear purposes. 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 opens with a clear action: 'Insert blank columns before the given column.' It specifies the resource (columns), operation (insert), and position (before given column). This is specific and distinguishes it from similar tools like insert_rows, which would insert rows instead.
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 lacks any guidance on when to use this tool versus alternatives such as insert_rows, delete_columns, or append_rows. It does not mention prerequisites (e.g., spreadsheet permissions) or context where this operation is appropriate. The usage is only implied by the tool's name and parameter list.
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?
Discloses key behaviors: destructive operation, snapshot before deletion, dry_run default true, and force param for exceeding cell limit. Given no annotations, description carries full burden and does well, though could mention irreversibility of delete.
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?
Efficient and front-loaded with critical info (destructive, dry_run default). Bullet-point args are clear and each sentence adds 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?
Covers all parameters and core behavior. No output schema but return value not critical here. Could mention error cases or confirmation, but sufficient for a deletion 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?
Adds meaningful information beyond schema: explains spreadsheet_id_or_url as URL or ID, sheet as name or gid, start_column as letter or 1-indexed number, dry_run defaults to TRUE, and force for limits. Schema description coverage was 0%, so description compensates fully.
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?
Clearly states 'Delete columns' with a note on destructive nature and dry_run default. Distinguishes from sibling tools like delete_rows and 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/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 versus alternatives like clear_range or delete_rows. The description does not compare to siblings or state 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?
No annotations provided, so description must disclose behavior. It lists parameters and mentions dry_run, but lacks details on what happens if the sheet already exists, error conditions, or side effects beyond creation. Adequate but with gaps.
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?
Description is concise: one sentence for purpose, then whitelist note, then bullet-like Args list. Every sentence adds value, with no redundancy. Front-loaded with key purpose.
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?
No output schema, so return values not needed. Covers all parameters and usage constraint. Missing error behavior and limitations (e.g., max rows/columns), but complete enough for a simple creation tool.
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 description must add meaning. The Args list explains all 6 parameters with clear descriptions (e.g., 'spreadsheet_id_or_url: Full Sheets URL or bare spreadsheet ID'). This compensates for missing schema descriptions, though could add constraints like row/column limits.
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 clearly states 'Add a new empty sheet (tab)', using verb 'add' and resource 'sheet'. This differentiates from sibling tools like delete_sheet or duplicate_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a whitelist note explaining when the tool is allowed ('writable_sheets is "*" or the new title is explicitly listed'), providing context for usage. Does not explicitly mention when not to use or alternatives, but the constraint is 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 clearly discloses partial updates, non-rollback behavior, and a dry_run parameter. It covers formatting details and border structure but omits potential limits like cell count 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main statement, a warning, and a parameter list. It is efficient but could omit the 'Args' section formatting slightly to reduce 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?
Given 11 parameters, 3 required, no annotations, and no output schema, the description covers parameter meanings adequately. It explains all optional parameters, but lacks specification of return values or success indicators.
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?
Despite 0% schema description coverage, the description provides detailed parameter explanations: formats for colors ('#RRGGBB'), border structure, range convention ('bare A1 without sheet prefix'), and dry_run purpose. This fully compensates for the schema gap.
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 clearly states 'Style cells' with specific behavior: 'Only the parameters you pass are changed; the rest is preserved.' This differentiates it from sibling tools that update values or set number formats.
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 warns about no rollback capability and suggests using Sheets version history, but does not explicitly compare with alternative styling tools or provide when-to-use/not-to-use guidance relative to siblings like set_number_format.
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 full burden and adequately discloses key behaviors: it never overwrites, explains dry_run returns an execution plan, raw stores inputs literally, and force allows bypassing cell limits. However, it does not describe the return format or pagination 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 highly concise: one sentence for the main purpose followed by efficient bullet points for each parameter. No redundant or extraneous information; every sentence adds 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?
Given the tool's moderate complexity (6 params, 3 required, nested rows, no output schema), the description covers core behavior, parameter details, and edge cases (force limit, dry_run). It lacks explanation of the dry_run execution plan format and return value structure, but overall it is sufficient.
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 provides detailed explanations for all 6 parameters, compensating for 0% schema description coverage. For example, it clarifies spreadsheet_id_or_url accepts 'Full URL or bare ID', sheet is 'name OR gid', rows is '2D list', and explains the effects of raw, dry_run, and force.
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 ('Append rows after the last data row of a sheet') and explicitly distinguishes it from overwriting, which differentiates it from sibling tools like update_range. The verb 'append' and resource 'rows' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies use for adding data without altering existing rows, it does not explicitly state when to use this tool versus alternatives like insert_rows or update_range. No direct 'when-to-use' or 'when-not-to-use' guidance is provided.
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 discloses key behaviors: it can set or clear a filter, accepts a range (or whole sheet), and includes a dry_run option to preview changes without applying. This covers the main behavioral traits, though destructive effects or authorization needs are not mentioned.
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: one sentence for purpose followed by a compact list of parameters. Every line adds value, and the main action is front-loaded. No superfluous content.
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 simplicity of the tool and absence of output schema, the description covers essential aspects: how to specify the sheet and range, the clear and dry_run flags. It could mention what happens on success or if filter already exists, but overall it is fairly complete 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?
Schema description coverage is 0%, so the description must fully explain parameters. It does so for all five: spreadsheet_id_or_url (URL or ID), sheet (name or gid), range (A1 or None for whole sheet), clear (remove filter), and dry_run (plan without changes). This adds substantial meaning beyond the raw 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 the tool's action: 'Set (or clear) the basic filter of a sheet.' It identifies the resource (sheet's basic filter) and the verb (set/clear), distinguishing it from sibling tools that deal with rows, columns, or sheets.
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 guide when to use this tool vs. alternatives. While the sibling tools are all different operations, there is no mention of when to use set_basic_filter over other filter-related tools (none exist in siblings), so implied usage is clear but no explicit context.
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 full burden. It details all parameters, includes a dry_run flag for previewing changes, and implies a write operation. However, it does not state permissions required or behavior if a rule already exists, which would enhance transparency.
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 moderately sized and front-loaded with the purpose. The bullet-point parameter list is clear but could be slightly more concise. Overall, it earns its space.
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 (10 parameters, 4 required, no output schema, no annotations), the description is comprehensive. It covers all parameter meanings, includes a dry_run option, and provides usage examples, making it complete enough for agentic 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 description coverage is 0%, so the description must explain all parameters. It does so thoroughly with examples (e.g., condition_values: ['100'] or ['=B2>C2']), adding significant meaning beyond the schema's type and title.
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 'Add a conditional-format rule to a range.' with a specific verb and resource. It distinguishes itself from sibling tools like set_basic_filter and set_cell_style, which handle different formatting 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 does not provide explicit guidance on when to use this tool versus alternatives like set_basic_filter or set_cell_style. The usage context is implied ('add a conditional-format rule') but no exclusions or sibling comparisons are given.
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?
Since no annotations are provided, the description carries the full burden. It discloses the important side-effect of whitelist name changes, which is valuable for agent planning. It does not mention authorization or reversibility, but the operation is straightforward.
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 purpose, a crucial note, then a clear parameter list. Every sentence serves a purpose, and the most critical information is front-loaded.
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 lacks information about the return value or success indication, which could help an agent verify the action. However, for a simple rename operation and given the whitelist note, the description is mostly 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 description coverage is 0%, so the description must compensate. It explains all four parameters (spreadsheet_id_or_url, sheet, new_title, dry_run) with clear, functional descriptions, fully covering their roles beyond the schema titles.
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 verb 'rename' and the resource 'sheet (tab)', immediately conveying the tool's purpose. It distinguishes from sibling tools like add_sheet, delete_sheet, and duplicate_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a practical note about updating whitelist entries after renaming, which guides correct use. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructiveness, snapshotting behavior, formatting not restored, and force parameter. Lacks authorization or rate limit info, but given no annotations, it is thorough enough.
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?
Concise with a clear summary followed by details and argument list. Slightly verbose but well-organized.
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 destructive tool with no output schema, it covers behavior, defaults, snapshotting, and edge case (large sheets). Complete enough for safe agent usage.
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?
With 0% schema coverage, the description explains all parameters: spreadsheet_id_or_url, sheet, dry_run (default TRUE), and force, adding 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 clearly states 'Delete an entire sheet' with a specific verb and resource, distinguishing it from sibling tools like clear_range or delete_rows.
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 guidance on dry_run default and how to actually delete, plus force parameter. Does not explicitly compare to alternatives but implies safe exploratory usage.
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?
No annotations are provided, so the description must convey behavioral information. It explains the dry_run parameter for safe execution and notes the whitelist constraint. However, it does not specify exactly what is duplicated (e.g., data, formatting, formulas) or potential side effects, leaving some ambiguity.
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 purpose, a brief whitelist note, and a clear parameter list. Every sentence adds value with no wasted words.
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 5 parameters, no output schema, and no annotations, the description covers purpose, permissions, and parameter details adequately. However, it could be more complete by mentioning what happens to the copied content (e.g., duplicates entire sheet including data and formatting) but is still sufficient for an agent.
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?
With 0% schema description coverage, the description fully explains each parameter: 'spreadsheet_id_or_url: Full Sheets URL or bare spreadsheet ID', 'sheet: Source sheet name OR gid string', 'new_title: Name for the copy', 'insert_index: Optional 0-based tab position', and 'dry_run: If true, return the execution plan'. This adds significant 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 clearly states 'Duplicate a sheet within the same spreadsheet.' This is a specific verb (duplicate) and resource (sheet), and it distinguishes from sibling tools like add_sheet, delete_sheet, and rename_sheet by indicating it creates a copy.
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 includes a whitelist note that provides permission context: 'allowed only when writable_sheets is "*" or the new title is explicitly listed.' This is a clear usage guideline. However, it does not explicitly mention when to use this tool versus alternatives like copying content manually.
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 fully discloses that only numberFormat is touched, other formatting is preserved, and changes are not rollback-capable. It also describes dry_run behavior. No mention of errors or limits, but sufficient for the tool's scope.
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 the primary purpose and key behaviors, and uses a clean Args list. Every sentence adds value without 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?
Given the complexity (6 params, no output schema), the description covers all parameters and key behaviors (dry_run, rollback). It lacks details about the normal return value, but is otherwise complete for this 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?
Since the input schema has no descriptions (0% coverage), the description provides clear explanations for all six parameters, including the acceptable values for type and the format for sheet and range. This fully compensates for the schema gap.
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 sets the number format of a range, provides examples of patterns, and distinguishes from sibling tools by noting that only numberFormat is touched and other formatting is preserved.
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 explains that only numberFormat is changed, implying when to use this over other formatting tools, and advises using Sheets version history for rollback. However, it does not explicitly name alternatives or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses overwriting behavior, formula interpretation, rollback snapshots, and dry-run return. All key behaviors are transparent.
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 a brief intro, a note on formulas, then a clear argument list. It is concise but could be slightly tighter; still efficient for 7 parameters.
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 no output schema and 0% schema coverage, the description provides comprehensive context for all parameters and behaviors. It is sufficient for an update tool with 4 required parameters.
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 explains every parameter: spreadsheet_id_or_url, sheet, range, values, raw, dry_run, force. This adds essential 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 clearly states 'Write values (or formulas) to an existing range. Overwrites current content.' This is a specific verb-resource combination that distinguishes it from sibling tools like append_rows or clear_range.
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 listing parameters and noting formula behavior, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions are mentioned.
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?
No annotations provided, so description carries full burden. It discloses destructive nature, snapshot before clearing, formatting not affected, dry_run default true, and force parameter. This is comprehensive behavioral disclosure.
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 a one-line summary followed by clear argument descriptions. It is well-structured and front-loaded, with every sentence adding 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?
The description covers behavior, parameters, and safety. However, it does not explicitly mention the return value or response format. Given no output schema, mentioning the snapshot or result would improve completeness.
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's 'Args' section explains all 5 parameters in detail, adding meaning beyond the schema names. For example, it clarifies the format of sheet and range parameters and explains dry_run default.
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 'Clear all values in a range' which is a specific verb+resource. It distinguishes from siblings like update_range or delete_rows by specifying that only values are cleared and formatting remains unaffected.
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 usage context with dry_run default and force parameter, but does not explicitly compare to sibling tools. It implies when to use by describing destructive nature and snapshot behavior.
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

google-sheets-write-mcp-server MCP server

Copy to your README.md:

[![google-sheets-write-mcp-server MCP server](https://glama.ai/mcp/servers/tg-tool/google-sheets-write-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/tg-tool/google-sheets-write-mcp-server)

Score Badge

Copy to your README.md:

[![google-sheets-write-mcp-server MCP server](https://glama.ai/mcp/servers/tg-tool/google-sheets-write-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/tg-tool/google-sheets-write-mcp-server)

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/tg-tool/google-sheets-write-mcp-server'

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