Loading ToolBench
MCP server providing access to Google Sheets, Gmail, and Google Calendar services through the Model Context Protocol
This server has 24 tools spanning Google Services (Sheets, Gmail, Calendar) and MongoDB. While tool names follow verb_noun convention and input schemas are present with type definitions, the implementation has significant gaps: (1) Most parameter descriptions are minimal (often just restating the name); (2) Output schemas are completely undocumented, no guidance on what fields agents should expect; (3) No error handling guidance, tools return raw API responses without actionable recovery hints; (4) Several parameters accept free-form JSON strings (e.g., 'query' in find_documents, 'pipeline' in aggregate) rather than structured types, inviting hallucination and parse errors; (5) No pagination or result limits documented despite tools that can return large datasets; (6) Missing descriptions for 'values' in append_sheet (only has description in write_sheet); (7) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Naming is solid (all tools start with action verbs and are verb_noun), but parameter quality and output documentation drag the average below 50.
Run MongoDB aggregation pipeline
Append data to a Google Sheet
Count documents in a collection matching a query
Create a new calendar event
Delete a calendar event
Delete a single document from a collection
Delete multiple documents from a collection
No output schemas documented. Tools return raw API responses without specifying what fields agents should expect. This forces LLMs to guess at response structure and blocks downstream tool chaining.
MongoDB tools accept free-form JSON strings for query, filter_query, update_data, and pipeline parameters. This invites hallucination and parse errors. Should use structured typed parameters (e.g., query as an object schema, not a string).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Find documents in a collection. Supports query, limit, skip, and sort options.
Get details of a specific calendar event
Get detailed information about a specific email
Get information about a Google Sheet
Insert a single document into a collection
Insert multiple documents into a collection
List upcoming calendar events
List all collections in a specific database
List all databases in MongoDB
List emails from Gmail
Read data from a Google Sheet
Search emails in Gmail
Send an email via Gmail
Update an existing calendar event
Update a single document in a collection
Update multiple documents in a collection
Write data to a Google Sheet
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Despite clear risk levels declared (READ_ONLY, WRITE, DESTRUCTIVE), agents cannot determine tool safety without reading descriptions.
No pagination or result limits documented. list_emails, list_calendar_events, list_databases, list_collections, find_documents all return potentially large result sets without specified caps or cursor/offset guidance.
Parameter descriptions are minimal and do not guide LLM usage. For example, 'query' in find_documents says only 'MongoDB query filter (JSON string, e.g. ...)' but does not explain when to use this vs count_documents or aggregate. Missing dependency hints like 'Call list_collections() first to see available collections.'
No error handling guidance. Tools do not specify what happens on invalid inputs, missing permissions, network failures, or ambiguous matches. For example, if multiple sheets match a spreadsheetId, what is returned? If a MongoDB filter matches zero documents, is that an error or an empty array?
append_sheet has no description for the 'values' parameter (unlike write_sheet which documents it as '2D array of values to write'). This creates ambiguity.
Destructive operations (delete_calendar_event, delete_document, delete_many_documents) do not mention confirmation or dry-run support. Agents cannot preview consequences before committing.
Gmail and Sheets credentials are injected via environment/config but the implementation does not document which env vars are required or how to validate authorization. Agents cannot self-diagnose permission failures.