Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Three tools with clear verb-noun naming (get_tables, get_columns, run_query) and documented schemas. Descriptions are present and reasonably detailed. However, parameter descriptions are generic and lack constraint documentation. Output format (CSV) is mentioned but not formally documented as a schema. Parameters lack enums where beneficial, format constraints, and expected value ranges. The server demonstrates competent basic structure but lacks the rigor expected of production-grade tools.
Tools (3)
{prefix}_get_columnsread only50/100
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.
{prefix}_get_tablesread only50/100
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.
Output schema not formally documented. Tools return CSV format (stated in descriptions) but no structured schema definition provided for what fields LLM should expect.
Parameter descriptions are minimal and lack format/constraint details. 'catalog', 'schema', 'table' parameters lack information about valid formats, lengths, character restrictions, or case-sensitivity. 'sql' parameter provides dialect info but lacks example valid statements, error handling guidance for invalid SQL.
run_query tool lacks pagination support. Executing arbitrary SELECT queries without limit enforces can return thousands of rows, exceeding context windows and degrading LLM reasoning.
{prefix}_run_query
Recommendations
Define output schema as structured JSON. Document expected CSV column headers for each tool (e.g., get_tables returns TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME; get_columns returns TABLE_NAME, COLUMN_NAME, TYPE_NAME, REMARKS). Replace free-text CSV returns with structured CallToolResult content that includes field types and descriptions.
Enhance parameter descriptions with format constraints and examples. Update 'table' description to: 'The unqualified table name. Must match DatabaseMetaData.getColumns() conventions for the connected dialect (case-sensitive for some, normalized for others). Example: "Users" for Salesforce, "users" for PostgreSQL.'
Add enum or pattern constraint for SQL clause validation in run_query. Update description: 'SQL SELECT statement. Supported clauses: FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT, OFFSET. Identifiers must be quoted with backticks or double quotes per dialect. Maximum 50,000 result rows returned; use LIMIT to enforce.'
Implement result pagination for run_query. Add optional 'limit' parameter (default 50, max 1000) and 'offset' parameter to control large result sets. Return metadata indicating total_rows_available and has_more_results.
Add recovery guidance to error messages. Catch SQLException and format errors like: 'Table "invalid_table" not found. Call {prefix}_get_tables to list available tables in this catalog/schema.' instead of RuntimeException wrapping.
Add input validation before executing queries. Validate table names against a whitelist (returned by get_tables), reject SQL with DROP/ALTER/DELETE/UPDATE keywords, validate SQL syntax before execution.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error handling guidance for LLM recovery. Tools throw RuntimeException on errors but provide no recovery hints (e.g., 'Table not found. Call {prefix}_get_tables to list available tables.').
No validation of parameter values before execution. Invalid table names, SQL syntax errors, and malformed catalog/schema strings will fail with generic RuntimeException messages rather than actionable guidance.
run_query tool description is extremely brief ('Execute a SQL SELECT statement.'), lacks context on when to use vs other tools, expected output structure, SQL dialect specifics, and constraints.
{prefix}_run_query
Expand run_query tool description from 36 to 150+ characters: 'Execute a read-only SQL SELECT query against the data source. Returns results as CSV with headers. Supports FROM, JOIN, GROUP BY, ORDER BY, LIMIT, OFFSET. Maximum 50k rows; use LIMIT to control result size. Identifiers quoted per dialect (backticks for MySQL, double quotes for PostgreSQL).'
Document interdependencies in descriptions. Update get_columns description: 'Call get_tables first to discover available table names. catalog and schema are optional and default based on the data source configuration.' This guides the LLM planning.
Add mutually-exclusive parameter note if catalog/schema are optional. Clarify: 'If your data source uses catalogs, specify catalog; if using schemas, specify schema. Both are optional depending on the dialect.'
Implement tool annotations (readOnlyHint) to signal these are safe to call repeatedly without side effects. All three tools should be marked idempotent and read-only.