Loading ToolBench
A Model Context Protocol server for accessing Zoho Projects data via JDBC/SQL interface. Enables querying and retrieving metadata about tables, columns, and executing SQL SELECT statements against Zoho Projects.
This server provides three database query and metadata tools with basic but incomplete definitions. All tools are properly registered with input schemas and descriptions, but the descriptions lack LLM-optimized detail and parameters have no individual descriptions. Naming is generic ('get_tables', 'get_columns', 'run_query') without actionable hints for when to use each tool. Schema quality is moderate, input parameters have types but lack individual descriptions. Output schemas are not documented. Error handling is minimal (generic RuntimeException thrown). The CSV output format is mentioned but not formally specified. Tools are read-only and composition-ready, but descriptions don't guide LLM decision-making.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `{prefix}_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 `{prefix}_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 completely undocumented. All three tools mention CSV format in descriptions but never formally specify the return structure. LLMs cannot plan downstream operations or extract specific fields when the response shape is invisible.
Individual parameter descriptions missing. Input parameters have types but no individual descriptions. E.g., 'catalog' and 'schema' parameters in get_tables lack descriptions of what they mean in the Zoho context, what values are valid, or what happens when omitted.
Tool descriptions do not guide LLM selection. There is no explanation of when to call get_tables vs get_columns vs run_query. An LLM seeing all three has to guess the intended workflow instead of understanding that get_tables → get_columns → run_query is the natural progression.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No error handling guidance. Generic RuntimeException is thrown on failure with only 'ERROR: <message>'. No attempt to categorize errors as retryable, user-fixable, or fatal. If a SQL query is malformed or a table doesn't exist, the LLM receives no actionable recovery hints.
SQL injection risk not mitigated in description. The 'sql' parameter in run_query accepts freeform SQL strings. While the description mentions using other tools to discover tables/columns, there is no warning about SQL injection, prepared statements, or input sanitization. An LLM could be tricked into injecting malicious SQL.
No pagination guidance. If run_query returns hundreds of rows, there is no mention of LIMIT/OFFSET best practices or result size limits. The description mentions LIMIT and OFFSET as valid clauses but doesn't enforce reasonable bounds or suggest a default page size.
No connection/authentication details visible. The Config object is used to create connections (config.newConnection()) but there is no documentation in the tool definitions about how credentials are provided, whether authentication is required, or what happens on auth failure.