Loading ToolBench
SAP HANA backend binding plugin for mcpg. Runs an operator-fixed SQL statement against a SAP HANA database over its native HDB SQL protocol and returns rows as JSON. The statement uses `?` positional placeholders bound from `params` — an ordered list of CEL expressions evaluated against the tool arguments. Values are bound as server-side prepared-statement parameters (never string-interpolated), so caller input cannot alter the statement (injection-safe). A read-only keyword guard fences the statement. The driver is `hdbconnect_async` — a pure-Rust HANA driver with rustls TLS (no native-tls / OpenSSL) and a bb8 connection pool.
Three tools with strong security posture (read-only, injection-safe prepared statements) and clear descriptions (150-180 chars each). However, input schemas are incomplete: hana_query lacks explicit parameter definitions beyond a generic 'arguments' object; list_tables and list_columns have basic string parameters but no type constraints (enums, patterns, length limits). Parameter descriptions are present but minimal (10-30 chars). No output schemas documented. Error handling guidance absent. Naming is verb-forward and clear (list_*, hana_query), following baseline conventions. Overall: solid foundation with security-first design, but schema rigor and output documentation lag production standards.
Execute an operator-fixed SQL statement against a SAP HANA database. The statement uses `?` positional placeholders bound from CEL-evaluated parameters. Values are bound as server-side prepared-statement parameters (injection-safe). A read-only keyword guard fences the statement.
List columns from SAP HANA catalog (SYS.TABLE_COLUMNS). Supports optional filtering by schema, table name, and column name. All filter values are bound as prepared-statement parameters (never interpolated).
List tables from SAP HANA catalog (SYS.TABLES). Supports optional filtering by schema, table name, and table type. All filter values are bound as prepared-statement parameters (never interpolated).
hana_query input schema is generic object with 'arguments' property but no explicit parameter definitions. LLM cannot infer what CEL expressions are valid or what the 'arguments' object should contain.
list_tables and list_columns accept optional string filters (schema, table, column) with no type constraints, length limits, or format guidance. No enum or pattern validation. LLM may pass invalid values.
No output schemas documented for any tool. LLM cannot predict response structure (field names, types, pagination). Breaks downstream tool chaining and forces guessing.
No error handling guidance. Descriptions do not explain what errors can occur, whether they are retryable, or what the LLM should do next (e.g., 'Connection failed, retry with exponential backoff').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Parameter descriptions are minimal (10-30 chars). 'Optional schema name filter' lacks context: is it a HANA schema? A namespace? What format? LLM reasoning suffers.