Loading ToolBench
MCP server for automating Google Sheets operations with CRUD functionality
The server defines 4 tools with partial schemas and brief descriptions. Two tools lack input schemas entirely (read-sheet has empty object {}), and descriptions are uniformly short (10-40 chars), below the production baseline of 194 chars. Parameter descriptions are present for write-sheet, update-sheet-row, and delete-sheet-row but lack clarity on contextual usage and error conditions. No documented output schemas, no error recovery guidance, and no response field structure. Tools are verb-prefixed (good naming) but descriptions are too terse to guide LLM selection. The server uses SDK tooling correctly but lacks the depth needed for confident production use.
Delete a specific row from the Google Sheet
Read rows from a Google Sheet
Update a specific row in the Google Sheet
Append a new row to Google Sheet
read-sheet has no input schema, defined as {} (empty object). Per hard scoring rules, schema score must be 0. This tool is unvalidatable and provides no guidance to LLMs on what (if any) parameters are supported.
All 4 tool descriptions are under 50 characters, well below the production baseline of 194 chars. 'Read rows from a Google Sheet' (29 chars) and 'Append a new row to Google Sheet' (34 chars) lack context on WHEN to use each tool, what constitutes success, and prerequisite setup. Per hard scoring rules, descriptions under 20 chars score ≤40; these are marginally better but still inadequate for LLM selection.
No documented output schemas. The code returns { content: [{ type: 'text', text: ... }] } but LLMs cannot see this structure from the tool registration. The read-sheet response will be formatted but its fields (row count, data structure) are invisible to the agent. Tools returning lists (read-sheet) lack pagination support and limit enforcement.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Error handling returns plain text messages ('Error reading sheet: ' + err.message) with no recovery guidance. Per pattern:recovery-guide, errors should tell the LLM what to do next. 'Error reading sheet: 403 Forbidden' gives the agent no action; 'Permission denied, ensure service account has access to the spreadsheet' would guide troubleshooting.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The code marks delete-sheet-row as DESTRUCTIVE and write-sheet as WRITE, but these are not surfaced via MCP annotations. Agents cannot distinguish safe (read-sheet) from irreversible (delete-sheet-row) operations without explicit metadata.
Parameter descriptions are inconsistent. 'Values for apples, bananas, oranges, grapes' is vague, does it mean 4 strings? Or exactly those 4 values in that order? 'Row number to update (starting from 2)' lacks the context 'why start at 2?' (answer: row 1 is headers). Descriptions should explain constraints and intent, not just enumerate fields.
No documented prerequisites or dependencies. The tools require Google Sheets credentials and a valid SPREADSHEET_ID, but callers cannot see this from tool definitions. Agents will not know to validate setup before invocation, leading to confusing errors.
read-sheet does not return metadata agents need for chaining. If the next step requires row numbers or column headers, they should be in the response. Current output is formatted text only, cannot be parsed by downstream tools.
update-sheet-row and delete-sheet-row operate on fixed column structure ('apples, bananas, oranges, grapes') hardcoded into descriptions. This violates flexibility, if column names change or sheets have different data, tools fail silently. No way to discover available columns or validate row structure.