Loading ToolBench
A Google Sheets MCP server and Claude Code plugin that makes sheets a brilliant, organized human would make.
gsheets-pro demonstrates solid tool design with consistent naming (verb_noun pattern), comprehensive parameter descriptions, and clear risk categorization. All 13 tools have descriptions (avg 95 chars) and input schemas with typed parameters. However, output schemas are not documented in the visible code, parameter descriptions lack format/constraint details (e.g., A1 range syntax, enum values for 'action' params), and error handling guidance is minimal. Tool composition is strong, each tool has a single responsibility and names clearly distinguish operations (sheets_read vs sheets_write vs sheets_find). The server follows the chat-data-model well by accepting tab names and A1 ranges rather than opaque IDs. Missing: documented return types, actionable error messages, and dry-run/confirmation patterns for destructive operations.
Send raw batch requests to Google Sheets API (escape hatch, skips named tool checks)
Run linting rules over a spreadsheet to find errors, warnings, and style violations
Apply conditional formatting rules to spreadsheet ranges
Find and locate data in a spreadsheet
Open a spreadsheet and return tabs, native Tables, named ranges, writable column contract, and dropdowns
Read data from a sheet tab, returning records keyed by header with _row field for true row numbers
Render a spreadsheet or range to an image (PDF or PNG)
Output schemas not documented. Tools return data but LLMs cannot plan downstream calls without knowing field names and types. sheets_open, sheets_read, sheets_find, sheets_check, sheets_render lack visible return type documentation.
Parameter descriptions lack format constraints. 'range' param appears in 7 tools but no description specifies A1 syntax (e.g., 'A1:C10', 'Sheet1!A1:B5'). 'action' enums in sheets_table and sheets_structure are declared but not explained (what does 'modify' do vs 'create'?).
Destructive operations (sheets_structure with delete_tab, delete_rows; sheets_batch with raw API) lack confirmation or dry-run patterns. An LLM could accidentally delete entire tabs or sheets without a safety gate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Modify spreadsheet settings like frozen rows, column widths, and other sheet properties
Modify spreadsheet structure: insert/delete rows or columns, sort, move tabs, rename tabs
Apply styling, formatting, banding, and themes to spreadsheet ranges or entire sheets
Create, delete, or modify native Tables in a spreadsheet
Create or modify data validation rules and dropdowns in a spreadsheet
Write data to a sheet, with formula guard and writable-column contract enforcement
sheets_batch is an escape hatch that bypasses named tool checks and accepts raw Google Sheets API requests. This is high-risk for prompt injection and unintended side effects. No validation or permission gating visible.
Error handling guidance missing. No visible error responses that tell LLMs what to do next (e.g., 'User not found. Try search_users()' pattern). Risk responses are labeled but recovery paths are not documented.