MCP server for Sybase IQ database access, providing tools to query tables, retrieve column metadata, and execute SQL statements
The server provides three well-named, appropriately scoped read-only SQL tools with clear descriptions and basic JSON Schema support. However, significant gaps exist in parameter documentation, output schema specification, and error handling guidance. Parameter descriptions are present but often minimal (e.g., 'The catalog name' for optional catalog parameter). No output schema documentation exists, LLMs cannot determine what fields to expect from CSV results. Error handling is minimal; exceptions are wrapped in generic RuntimeException without recovery guidance. The tools follow the verb_noun naming pattern correctly and avoid overly generic names, but the implementation lacks the rigor expected of production-grade database connectors.
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 output schema documentation. Tools return CSV-formatted strings but provide no documentation of which columns will be present, data types, or field names. LLMs cannot parse or validate results without schema info.
Parameter descriptions are minimal (e.g., 'The catalog name', 'The schema name'). They lack actionable format guidance, valid value ranges, or usage context. Baseline for A-tier tools is 72+ chars per parameter description; these average ~20 chars.
No pagination or result limiting. Tools return all matching tables/columns/rows with no page/offset/limit support. Large schemas will bloat responses and waste context window tokens.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Error handling provides no recovery guidance. Exceptions are wrapped as 'ERROR: {message}' with no indication of whether the error is retryable, user-fixable, or fatal. The LLM cannot plan recovery steps.
SQL tool description does not explain the SQL dialect limitations (supports FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET) in a way LLMs can reliably use. The description contains this info but buries it in a clause list rather than stating 'This tool supports basic SQL SELECT with these specific clauses: ...'
No idempotency hints or destructive operation markers. While these are read-only tools (good), the tool definitions lack readOnlyHint annotations in schema. This makes capability discovery harder for agent planning.