Loading ToolBench
An MCP server that provides database access tools for SAP HANA XS Advanced via JDBC, allowing retrieval of tables, columns, and execution of SQL queries
This server defines 3 tools with basic functionality (get_tables, get_columns, run_query). Tools have descriptions and input schemas present, but the definitions have significant gaps. Descriptions are terse but adequate. Parameter schemas exist with type declarations and basic descriptions. However, there is NO documented output schema for any tool, the response format (CSV with headers) is mentioned only in tool descriptions, not as a formal schema structure. Error handling is minimal: exceptions are caught and re-thrown as RuntimeException with a message, providing limited recovery guidance. Security is reasonable (READ_ONLY operations only, no credential exposure), but there are no per-tool permission annotations or scope declarations. Composition is sound, tools are single-purpose and can be chained (get_tables → get_columns → run_query). Average across 3 tools: (55 + 50 + 52) / 3 = 52.
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.
No documented output schemas for any tool. Descriptions mention 'CSV format' in text, but there is no formal schema declaration (e.g., McpSchema.ObjectSchema with fields, types, and descriptions) for the response structure. LLMs cannot reliably parse CSV output or plan downstream operations without a schema.
Error handling is minimal and non-actionable. The run() methods catch exceptions and re-throw as RuntimeException with a message. No guidance on whether errors are retryable, what the user should do, or available alternatives (e.g., 'Column not found. Available columns: ...').
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While all tools are READ_ONLY (no modifications), this should be explicitly declared in the tool definition via isReadonly=true or similar, not just inferred from the description. Makes planning and safety verification harder for agents.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Parameter descriptions are terse and lack format/constraint details. For example, 'catalog' and 'schema' descriptions are single-word ('The catalog name', 'The schema name'). 'sql' parameter lacks guidance on injection safety, identifier quoting, or supported SQL dialect version.
CSV response format is fragile. No pagination or limit guidance. If a table has thousands of rows, run_query will return all of them as CSV, risking context window exhaustion.
'run_query' tool accepts raw SQL input but does not validate or sanitize it. While the tool is READ_ONLY, no mention of SQL injection prevention or input validation.