Loading ToolBench
The server defines 4 tools with mixed quality. Tool naming is action-verb based and clear (list_*, run_*). Descriptions are present but vary significantly in detail and LLM-optimizability. `run_query` has an exceptionally detailed description (600+ chars) that exceeds best practices for token efficiency; others are concise but adequate. Input schemas are properly typed and visible. A critical issue: only 1 of 4 tools has parameter descriptions in the visible schema (`list_tables` has 'description' for the 'database' parameter; `list_databases` has empty input; `run_query` input shows no parameter descriptions; `run_chdb_select_query` input shows no descriptions). Output schemas are not documented anywhere in the provided source. Error handling guidance is absent, tools do not explain what to do on failure, retryability, or recovery paths.
List available databases in ClickHouse
List tables in a ClickHouse database
Run SQL in chDB, an in-process ClickHouse engine. Integers outside [-9007199254740991, 9007199254740991] are returned as decimal strings.
Execute SQL queries in ClickHouse. Queries run in read-only mode by default. Bind optional params by name with {name:Type} placeholders, such as {name:String} or {vector:Array(Float32)}. Values may be JSON scalars, nulls, or arrays. Pass exact large integers as decimal strings. JSON lists and objects cannot bind to Tuple and Map types. Python percent formatting and $name$ raw binary parameters are not supported. Parameter values stay out of the MCP server's normal SQL log lines, but may appear in errors and backend logs. Set CLICKHOUSE_ALLOW_WRITE_ACCESS=true to allow DDL and DML operations. Set CLICKHOUSE_ALLOW_DROP=true to additionally allow destructive operations (DROP, TRUNCATE, DELETE, UPDATE, REPLACE TABLE/PARTITION, CREATE OR REPLACE, CLEAR COLUMN/INDEX/PROJECTION, DETACH PERMANENTLY). That gate is a best-effort accident guard, not a security boundary. Integers outside [-9007199254740991, 9007199254740991] are returned as decimal strings. Two optional checks also run through this tool. Use DESCRIBE (<query>) when you need a query's output columns and types; it inspects the result schema and surfaces analysis errors such as an unknown column, but a query that describes cleanly can still fail at runtime. Consider EXPLAIN ESTIMATE <query> before a SELECT that could be expensive; it returns the estimated parts, rows and marks read from MergeTree family tables, which is not run time and not result size. Neither runs the query body, though analysis can execute scalar subqueries.
Output schemas not documented. No tool describes what fields, types, or structure it returns. LLMs cannot plan downstream calls or extract typed data from responses.
`run_query` description (600+ chars) exceeds token-efficient baseline of 10-1024 chars ideal (194 avg). The description buries key operating constraints (read-only mode, parameter binding syntax, write-enable flags) in verbose prose, making it harder for LLMs to extract intent vs. implementation details. Should be split: core description (50-100 chars) + separate schema constraints for parameters.
Parameter descriptions missing or incomplete. `run_query` and `run_chdb_select_query` show input schema with 'query' param but no description visible in the source. `list_databases` has empty `{}` input schema with no parameters to describe. Only `list_tables` explicitly documents the 'database' parameter. Best practice: 100% of tool params must have descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No error handling guidance. Tools do not describe error conditions, retryability (e.g., timeouts, connection failures), or recovery paths. 'Invalid query' or 'Database not found' errors would be returned without actionable next steps for the LLM.
`list_databases` and `list_tables` do not document pagination. If a ClickHouse instance has many databases or tables, results could exceed context limits. No mention of limit, offset, page_size, or next_cursor in visible schemas or descriptions.
`run_query` exposes a verbose parameter-binding syntax in the description ('Bind optional params by name with {name:Type} placeholders...') but does not provide a dedicated parameter for this in the schema. The 'query' parameter appears to be a single string; unclear how LLMs should format parameterized queries without a 'params' or 'bindings' parameter.