Loading ToolBench
MCP server for Google Workspace APIs (Sheets, Calendar, Gmail, Drive, Tasks)
Server has 2 tools with clear action verbs and documented schemas. Descriptions are present and moderately detailed. However, parameter descriptions are inconsistent: get_time has a single well-described param; query_sheet has 8 params with mixed quality. Several parameters in query_sheet lack clarity about constraint interactions (e.g., mode affects how filters.field is interpreted). Output schemas are not explicitly documented. Error handling in descriptions exists but lacks recovery guidance per pattern:recovery-guide. No tool annotations (readOnlyHint/destructiveHint) present despite being marked READ_ONLY in metadata.
Returns the current date, time, and day of week for the specified timezone. Requires IANA timezone format (e.g. 'America/New_York', 'Europe/London', 'Asia/Tokyo', 'UTC'). If user's timezone is unknown, ask them.
Query a Google Sheet with flexible filtering. Returns matching rows with _row_number. Results always use column letters as keys (e.g. "A", "B"). Filters support: - {'field': 'Company', 'operator': '==', 'value': 'Acme'} (mode: header) - {'field': 'A', 'operator': '==', 'value': 'Acme'} (mode: letter) Operators: ==, !=, >, <, >=, <=, in, not in, contains, not contains, is_null, not_null Date/time operators (==, !=, >, <, >=, <=) automatically parse datetime values. IMPORTANT for date filtering: - Use == with a FULL date string (e.g. '1/27/2026' or '2026-01-27') for exact date matching. - Do NOT use 'contains' for dates — it does substring matching (e.g. '1/27' matches '11/27/2025'). - Supported date formats: m/d/YYYY, YYYY-MM-DD, m/d/YYYY h:MM AM/PM, YYYY-MM-DD HH:MM:SS. - The filter value format must match what's stored in the sheet cells.
query_sheet parameter descriptions lack clarity on interdependencies. The 'mode' parameter determines how 'filters[].field' is interpreted (header name vs column letter), but this dependency is not documented in the filters parameter description. Users/LLMs cannot understand valid combinations without reading both descriptions together.
Output schemas are not documented. The tool descriptions explain inputs well but do not specify what fields the response contains. LLMs cannot plan downstream operations or chain this tool's results into other tools without guessing response structure. For query_sheet, users must infer that results use column letters as keys.
No tool annotations present. Both tools are marked READ_ONLY in metadata but the tool definitions themselves lack readOnlyHint or idempotentHint annotations. This violates Spec Alignment, tool annotations are current patterns in MCP 2026-07-28 and essential for agent safety (distinguishing side-effect-free tools from destructive ones).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error messages in query_sheet do not follow recovery-guide pattern. When a header is not found, the error includes available headers but does not suggest what to do next (e.g., 'Try mode="letter" to reference columns by letter instead'). Date parsing errors are not handled, malformed dates silently fail filtering.
query_sheet allows filters array but does not document operator constraints. Description mentions operators (==, !=, >, <, etc.) and date/time handling but does not specify which operators apply to which data types, when date parsing occurs, or how to handle null values in filters. An LLM cannot reliably construct valid filters.
Parameters limit and sort_by lack bounds and validation rules in descriptions. 'limit' has no stated min/max; 'sort_by' does not clarify if it accepts header names, column letters, or both (dependent on mode). LLMs will pass invalid values without guidance.