Loading ToolBench
MCP server for HCL Domino database connectivity via JDBC, enabling SQL queries and metadata discovery
This server has 3 database query tools with reasonable naming and complete JSON schemas. However, the tool descriptions lack LLM-specific guidance about tool selection and usage patterns. Output is CSV-formatted text without documented structure for parsing, making downstream chaining difficult. Parameters are typed and named clearly, but parameter descriptions are minimal (e.g., 'The catalog name' leaves ambiguity about whether catalog is required, what values are valid, or how it relates to schema). Error handling returns raw exceptions as RuntimeException with message concatenation rather than structured error responses. The server composition follows a logical discovery pattern (tables → columns → query), but lacks pagination guidance for large result sets.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `domino_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 `domino_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.
Tool descriptions lack actionable LLM guidance. Descriptions state WHAT tools do but not WHEN to select them vs similar tools or how to handle prerequisites. E.g., domino_run_query says 'Execute a SQL SELECT statement' without explaining that domino_get_tables must be called first to discover valid table names, or that column names must be quoted. This forces LLMs to discover patterns through trial and error.
Parameter descriptions are minimal and leave ambiguity. 'The catalog name', 'The schema name', 'The table name' do not explain whether these are required, optional, case-sensitive, or how they interact. For domino_get_tables and domino_get_columns, the descriptions say 'Both catalog and schema are optional' in the tool description but individual parameter descriptions do not repeat this constraint.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Output structure is not documented. All three tools return CSV format with 'first line containing column headers', but there is no documented schema for what fields are in the CSV or how many rows may be returned. Without documented output schema, LLMs cannot plan downstream operations or extract required data. Baseline: 100% of A+ tools have documented return types.
No pagination guidance or limits documented. Tools return CSV results with no indication of result limits, pagination support, or maximum row counts. If a table has thousands of rows, domino_run_query could return an unbounded result set, exhausting context and blocking the agent.
Error handling returns raw exceptions as RuntimeException with message string concatenation. There is no classification (retryable vs fatal), no recovery guidance, and no validation of invalid parameter values before execution. E.g., if an LLM passes an invalid table name, the tool throws an unstructured exception instead of guiding the LLM to call domino_get_tables first.
LLMs tend to reuse example values literally, and the note about '\"\"' quoting for identifiers is cryptic. Should document with a clear pattern.