MCP server for executing SELECT queries on SQL databases (MSSQL, MySQL, PostgreSQL) with read-only access and schema discovery
This server provides 4 read-only database tools with basic descriptions and no input schemas beyond the query parameter. Tool naming follows verb_noun convention (execute_, get_, list_), but descriptions are minimal (avg 12-25 words, well below the 50-200 char LLM-optimized baseline). Parameters lack type annotations in the schema objects, most tools accept empty objects {}. The execute_select_query tool has a single 'query' parameter with a string type and basic description, but the other three tools declare no parameters at all, making their schemas incomplete. Error handling is minimal: the isSelectQuery validation provides some protection against injection, but there are no recovery hints for LLMs. No output schemas are documented. The server demonstrates basic competence in security (read-only mode, dangerous keyword filtering) but lacks the polish and detail expected of production-grade tools.
Execute a SELECT query on the database. Only SELECT queries are allowed for security. Returns the query results with rows and column information.
Get the complete database schema including all tables and columns with their data types
Get foreign key relationships between tables
List all tables in the database
Four of four tools have no documented output schemas. LLMs cannot infer the fields returned by get_database_schema, list_tables, or get_table_relationships, forcing them to guess at field names and structures.
Descriptions for get_database_schema, list_tables, and get_table_relationships are all under 30 characters and lack WHEN-to-use guidance. Per pattern:tool-description, descriptions should include context for tool selection and dependencies (e.g., 'Call this first before executing queries to understand available tables').
No error handling guidance. The execute_select_query tool validates against SQL injection via isSelectQuery(), but if validation fails, the LLM receives only 'Only SELECT queries are allowed for security reasons'. No recovery hint (e.g., 'Try rewording your query to use only SELECT, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
execute_select_query has no output schema documented. While the implementation returns {rows, rowCount, columns}, LLMs have no formal definition of these fields, their types, or whether columns is populated for all database types (MySQL field info structure differs from MSSQL's).
Parameter descriptions for execute_select_query are minimal ('The SELECT SQL query to execute'). No guidance on query length limits, performance expectations, complexity constraints (e.g., 'Queries must execute within 30 seconds'), or result size caps.
No tools support pagination or result limits. If a query returns 10,000 rows, all are returned. Per pattern:paginated-result, tools returning lists should accept limit/offset and cap results to 20-50 items by default.