Loading ToolBench
MCP server providing SQL-based access to Jira Service Management data via JDBC connector, exposing tables, columns, and query execution capabilities
The server defines 3 tools with basic structure and schema support, but exhibits significant gaps in description quality, parameter validation, and error handling. All tools are read-only and follow a data-exploration pattern (get_tables → get_columns → run_query), which is sound in composition. However, descriptions are generic, output schemas are undocumented, and error handling is minimal. The codebase is well-organized but lacks LLM-optimized guidance.
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. All three tools mention CSV output format in descriptions, but LLMs cannot plan downstream operations or extract fields without a formal output schema declaration. This violates the pattern:tool-description requirement that LLMs must know what fields to expect.
Parameter descriptions are generic and lack actionable constraints. E.g., 'The catalog name' tells an LLM nothing about valid values, format, or when to omit. No guidance on enum values, format patterns, or mutual dependencies between catalog/schema/table parameters.
No error recovery guidance. CallToolResult is hardcoded to throw RuntimeException on failure with 'ERROR: ' prefix. LLMs receive no actionable guidance on what to try next, whether the error is retryable, what caused it, or which tool to call for remediation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | 0.8.1+ | v1 |
No pagination support or result size limits documented. The run_query tool mentions LIMIT/OFFSET syntax is supported, but no guidance on maximum result rows, timeout behavior, or what happens if a query returns 100k rows. This risks context window exhaustion.
Descriptions lack discovery-phase guidance. LLMs should know 'Call get_tables first to explore available sources' and 'After get_tables, use get_columns to inspect structure before querying.' Workflow dependencies are implicit, not explicit.
Security: No permission checks documented. The tools accept optional catalog/schema parameters and execute arbitrary SELECT queries. No indication that these operations are gated by user authorization, row-level security, or connection credentials.