Loading ToolBench
MCP server for querying data sources via JDBC with SQL support. Provides tools to list tables, retrieve columns, and execute SQL queries against any JDBC-compatible database.
The server defines 3 tools with basic schemas and descriptions. All tools have input schemas with proper JSON Schema structure and type declarations. Descriptions are present but generic and lack operational guidance. Parameters are documented but lack constraints, enums, and dependency information. Output format is mentioned (CSV) but return schemas are not formally documented. Error handling is minimal, exceptions are wrapped in generic RuntimeException with basic message concatenation. No tool annotation hints (readOnlyHint, etc.) despite all being read-only operations. The naming convention (verb_noun with prefix) is sound, but descriptions don't explain WHEN to use each tool relative to others or provide chain guidance.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `google_search_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 `google_search_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.
Descriptions are generic and lack operational context. E.g., 'Execute a SQL SELECT statement' tells the agent WHAT but not WHEN to use it, what query patterns are valid, or what constraints exist. Should include: valid SQL clauses (FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET), identifier quoting rules (backticks), and examples of invalid operations (UPDATE, DELETE, INSERT are not supported).
No output/return schema documented. Tools return CSV format as mentioned in descriptions, but the agent cannot reason about the structure of returned data (column names, field types, pagination behavior). Tools should document: 'Returns CSV with headers on first line. Columns include: [list]. Max rows: [limit]. If results exceed limit, return first N rows and indicate total count.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Parameters lack constraints and dependent relationships. 'catalog' and 'schema' are optional in get_tables and get_columns, but no guidance on: (1) how omitting one affects the result set, (2) whether they are mutually dependent, (3) what default behavior is. The 'table' parameter is marked required in get_columns but required in run_query description mentions backtick quoting, this constraint is not reflected in schema.
No tool annotations. All three tools are read-only operations with no side effects, but none declare the 'readOnlyHint' annotation. This means agents cannot distinguish read-only tools from mutation tools without manual reasoning, leading to inefficient planning and unnecessary confirmation prompts.
Error handling is minimal and not actionable. Exceptions are caught and wrapped as 'ERROR: ' + message. If a table is not found, or a catalog is invalid, the error message may be cryptic (raw SQL exception). Errors should: (1) categorize as user-fixable (invalid table name) vs. unrecoverable, (2) suggest recovery steps (e.g., 'Table not found. Try google_search_get_tables() to list available tables.'), (3) include the invalid value and constraint violated.
No pagination guidance. If get_tables or get_columns returns thousands of rows, no limit is enforced and no pagination mechanism (offset, limit, cursor) is offered. Baseline: production tools cap results at 20 - 50 items and require pagination for more. This will exhaust context and degrade LLM reasoning on large datasets.
Tool composition assumes agent knows discovery order. To write a SQL query, the agent must first call get_tables() to find table names, then get_columns() to find column names, then run_query(). This workflow is not documented as a recommended sequence. Descriptions should say: 'First, call google_search_get_tables() to list available tables, then google_search_get_columns() to inspect a table, then google_search_run_query() to fetch data.'
run_query description mentions valid/invalid SQL clauses inline ('Valid clauses: FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET') but does not use an enum or formal constraint in the schema. This is documentation debt, the description text is not machine-parseable and can easily diverge from actual validation.