MCP server that provides tools to query and interact with databases via JDBC connectivity. Supports multiple data sources through configurable JDBC drivers.
The server defines 3 tools with basic schemas and descriptions, but multiple critical gaps prevent a higher score. All tools have descriptions and input schemas visible in the code, but descriptions lack depth and actionability. Parameter descriptions are minimal (1-2 words each). No output schemas are documented, only a mention that results are 'CSV format'. Error handling is absent: exceptions are caught and re-thrown as generic RuntimeExceptions with no guidance for LLM recovery. No validation hints, no parameter constraints, no enum values despite opportunities (e.g., query clauses could be constrained). Tool names follow verb_noun pattern (get_*, run_*), which is positive. However, the tools lack composition support, no pagination, no result limiting documented, no IDs returned for chaining. The schema builder code shows proper JSON Schema generation with types, but parameter descriptions are truncated placeholders.
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.
Output schemas not documented. Tools state they return 'CSV format' but no structured schema is declared. LLMs cannot infer field names, types, or how to parse results.
Parameter descriptions are minimal (1 - 2 words: 'The catalog name', 'The schema name', 'The table name'). Baseline is 72 chars avg; these lack context on when to supply, what format, valid values, or examples.
run_query tool description mentions SQL dialect (SQL-92) and valid clauses but does not warn against DDL/DML. LLMs could attempt INSERT, UPDATE, DELETE, or DROP. Tool is described as SELECT only, but no runtime validation is visible to prevent misuse.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No error handling guidance. GetColumnsTool.run() catches exceptions and throws new RuntimeException('ERROR: ' + ex.getMessage()). No recovery hints for LLM. If a table doesn't exist, the agent has no guidance to call get_tables first.
No pagination or result limiting documented. If get_tables returns 10,000 tables or run_query returns 50,000 rows, context window is blown. Tools need limit/offset parameters and documentation.
Tool composition is weak. get_tables returns table names, but no indication of which columns identify a table (catalog/schema/name tuple). If run_query fails, no metadata returned to simplify retries.
Parameter named 'sql' for run_query lacks format/pattern constraints. Description says 'SELECT statement' but no validation prevents 'DROP TABLE users'. LLM cannot self-validate input.