Loading ToolBench
MCP server for Apache HBase that provides tools to query and explore HBase tables via a JDBC interface
This server defines 3 tools with reasonable naming conventions (all start with action verbs: hbase_get_*, hbase_run_*). Descriptions are present and adequate (120-180 chars range, within baseline 194 avg), explaining WHAT each tool does and WHEN to use it. Parameter schemas are explicit with types and descriptions present for all parameters. However, there are significant gaps: no documented output schemas (critical for tool composition), no error handling guidance (tools throw RuntimeException without recovery hints), no pagination support despite CSV output potentially being large, and no parameter constraints (enums, ranges) on potentially ambiguous inputs. The 'sql' parameter description is verbose but lacks format constraints and examples of valid vs invalid queries. No tool annotations (readOnlyHint, etc.) despite all tools being read-only, this misses a machine-readable safety signal. Overall, the tools are functional but lack production polish around output documentation, error recovery, and result limiting.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `hbase_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 `hbase_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.
No documented output schemas for any tool. LLMs cannot plan downstream calls without knowing return types, pagination fields, or available IDs for tool chaining.
Tool descriptions lack sufficient detail. hbase_run_query's description 'Execute a SQL SELECT statement.' is only 31 chars, well below 50-200 char baseline for production tools. No guidance on when to use (vs direct SQL in client?), no error recovery hints, no result limits stated.
No error handling guidance. All tools throw RuntimeException('ERROR: ' + ex.getMessage()) without categorizing errors as retryable, user-fixable, or fatal. An LLM gets no instruction on what to do next if a query fails.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | - | v1 |
No result limits or pagination. CSV output is unbounded, returning 100k columns or 100k table rows will exhaust context window. No limit, offset, or page_size parameters; no pagination hint in descriptions.
No parameter constraints. SQL parameter lacks regex pattern, max length, or explicit examples of valid vs invalid queries. catalog/schema parameters lack enum or pattern constraints. LLMs may hallucinate invalid values.
Missing tool annotations. All tools are read-only but lack readOnlyHint annotation in schema. This is a machine-readable signal that helps LLMs avoid safety checks and confidence issues. Current MCP spec (2026-07-28) supports tool annotations but they are not used.
Parameter descriptions do not include format or constraint details that LLMs should parse. E.g., 'catalog' and 'schema' descriptions are bare ('The catalog name', 'The schema name') without guidance on format, allowed characters, or examples. 'table' parameter likewise lacks actionable constraint info.