Loading ToolBench
MCP server providing SQL-based access to Gmail and other data sources via JDBC drivers
This Gmail MCP server implements three read-only data discovery and query tools with partial schema documentation and inconsistent parameter descriptions. All tools have visible input schemas with basic types and required constraints. Descriptions exist for all tools and most parameters, but fall short of LLM-optimization standards. Critical gaps: (1) Output schemas are not documented, the server returns CSV but LLMs cannot parse the exact field structure without seeing it; (2) Parameter descriptions are minimal and lack constraint guidance; (3) No error handling guidance, thrown exceptions lack recovery hints; (4) STDIO transport prevents remote deployment. The server follows a consistent pattern (tool registration via ITool interface, JsonSchemaBuilder for input schemas) but lacks production-grade polish around parameter validation, output shaping, and error messaging.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `gmail_get_tables` tool to get a list of available tables. The output of the tool will be returned in CSV format, with the first line containing column headers.
Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source. Use the `gmail_get_columns` tool to list available columns on a table. Both `catalog` and `schema` are optional parameters. The output of the tool will be returned in CSV format, with the first line containing column headers.
Execute a SQL SELECT statement.
Output schemas not documented. All three tools return CSV format but the LLM cannot determine which columns will appear or their types without external knowledge. RFC 7111 CSV format lacks schema, the server should document expected column names, types, and sample output structure.
Parameter descriptions lack constraint guidance. The 'sql' parameter in gmail_run_query states 'The SELECT statement to execute' but provides no bounds on query complexity, timeout behavior, result row limit, or JOIN depth. Unbounded SQL parameters invite LLM-generated queries that may fail or timeout.
No error recovery guidance. The GetColumnsTool.run() method throws 'RuntimeException("ERROR: " + ex.getMessage())'. The LLM receives 'ERROR: unknown table' with no hint on what to do next (e.g., 'Call gmail_get_tables to discover valid table names'). Errors should guide recovery.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Tool descriptions omit WHEN and WHY. 'Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source' does not explain the discovery workflow. LLMs need: 'Call this first to discover available tables, then use gmail_get_columns to inspect a specific table before writing SQL with gmail_run_query.'
CSV output format unstructured for LLM parsing. CSV is human-readable but forces LLMs to parse unstructured text. Returning structured JSON with typed fields (e.g., {'tables': [{'name': 'Inbox', 'rowCount': 1250}]}) would be more LLM-friendly and reduce hallucination risk.
gmail_run_query description buries key constraints in body text. 'Valid clauses: FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET' should be extracted into parameter constraints or a separate 'Limitations' section. LLMs are poor at parsing complex descriptions embedded in prose.
No pagination or result limits documented. gmail_run_query accepts arbitrary SQL with no stated result row limit. If a user queries a large mailbox, the response could explode the context window. The tool should enforce LIMIT 100 (or similar) and document this in the description.