This server has severe definition quality issues across all three tools. All tool descriptions are extremely brief (under 100 chars), lacking the LLM-optimization guidance specified in the rubric. Input schemas are either empty objects or minimally typed. Parameter descriptions are missing entirely. The tools lack context about when to use them, what they return, and how they chain together. Error handling is minimal, there is no recovery guidance, no actionable error messages, and no indication of which errors are retryable. The server shows foundational code quality but fails basic MCP tool definition standards.
Tools (3)
connect_dbread onlyauthsource verified20/100
Env üzerinden MSSQL bağlantısını test eder.
discover_schemaread onlyauthsource verified22/100
Tablo/kolon keşfi ve heuristik etiketler (date_cols, measures, dims).
run_sql_saferead onlyauthsource verified38/100
Yalnızca tek SELECT ifadesi çalıştırır; DDL/DML yasak; TOP limiti otomatik enjekte edilir.
connect_db and discover_schema have completely empty input schemas ({}). No parameters are documented, making it impossible for LLMs to understand what the tool accepts.
All three tool descriptions are extremely brief and generic (55-90 chars). Rubric baseline for effective descriptions is 194 chars average; descriptions under 20 chars cannot score above 0-20. These descriptions fail to answer: What does it do? When should the LLM call it? What does it return? This forces LLMs to guess.
run_sql_safe accepts a 'sql' parameter but the schema only shows {"sql": {"type": "string", "description": "SQL SELECT statement to execute"}}. No parameter constraints are documented, no mention of maximum length, forbidden keywords beyond the basic guard(), or examples of valid input. LLMs cannot infer that DDL/DML are blocked without reading the description.
run_sql_safe
Recommendations
Expand connect_db description to 100-200 chars. Clarify: 'Test connection to the MSSQL database configured via environment variables. Returns success or connection error details. Call this first to verify the database is accessible.' Add a note: 'This tool does not maintain a persistent connection, each database operation opens and closes its own pool.'
Expand discover_schema description to 150+ chars. Clarify: 'Scan the MSSQL database schema and catalog all tables, columns, and data types. Applies heuristic labels (date_cols, measures, dims) to aid query generation. Returns a list of discovered tables. Call this once at the start before run_sql_safe.' Document output: 'Returns schema.table names. Populates internal metadata.'
Expand run_sql_safe description to 150+ chars and add constraints: 'Execute a single SELECT statement against the discovered schema. Only SELECT queries allowed, DDL/DML (CREATE, DROP, INSERT, UPDATE, DELETE) are rejected. Results are capped at 5000 rows via automatic TOP injection. Requires discover_schema to have been called first.' Add parameter description for 'sql': 'A SELECT statement. Must not contain ; (semicolon), --, /*, CREATE, DROP, ALTER, INSERT, UPDATE, DELETE, MERGE, EXECUTE, EXEC, XP_, GRANT, REVOKE, BACKUP, RESTORE, or TRUNCATE keywords. Subqueries are allowed.'
Define output schemas for all three tools. Example for run_sql_safe: '{ "type": "object", "properties": { "rows": { "type": "array", "items": { "type": "object" }, "description": "Result set (max 5000 rows)" }, "rowCount": { "type": "integer" }, "message": { "type": "string" } }, "required": ["rows", "rowCount"] }'. Similar for connect_db and discover_schema.
No output schemas documented for any tool. Rubric baseline: 100% of A+ tools have documented return types. LLMs need to know: Does connect_db return a boolean or a detailed connection object? Does discover_schema return table names, column lists, or the full catalog? Does run_sql_safe return raw rows or a structured result? The ambiguity invites misuse.
Error handling is absent. guard() returns a boolean; enforceTop() returns modified SQL. But what happens when the MSSQL connection fails? When a query times out? When the catalog is empty? There is no recovery guidance, no 'retryable' classification, no 'user-fixable' hints, no suggestions for next steps. LLMs will not know whether to retry, ask the user, or give up.
Tool naming issues: 'connect_db' is vague, does it establish a persistent connection or just test connectivity? 'discover_schema' is not action-oriented (missing 'get_' prefix). 'run_sql_safe' uses the generic verb 'run' rather than 'query_' or 'execute_'. These names do not clearly distinguish intent from related database tools.
No documentation of tool dependencies or chaining. LLMs do not know that discover_schema must be called before run_sql_safe (to populate the CATALOG). Descriptions should say: 'Call discover_schema first to load the database catalog.' This prevents wasted calls and guides multi-step planning.
run_sql_safe enforces a 5000-row TOP limit, but this is not documented in the schema or description. LLMs may pass unbounded queries expecting full results, then be surprised by truncation. The description should state: 'Results are capped at 5000 rows automatically via TOP injection.'
run_sql_safe
Add explicit error handling to each tool handler. Return structured error responses: '{"error": true, "code": "CONNECTION_FAILED", "message": "MSSQL connection failed: <details>", "retryable": true}' for connect errors. 'GUARD_REJECTED' for SQL injection attempts (retryable=false, user-fixable=true). 'TIMEOUT' for slow queries (retryable=true).
Rename tools to be more action-oriented: 'connect_db' → 'test_mssql_connection'; 'discover_schema' → 'get_mssql_schema'; 'run_sql_safe' → 'query_mssql' (or 'execute_select_query'). Verb_noun naming helps LLMs parse intent.
For connect_db and discover_schema, define proper input schemas even if empty of required parameters: '{"type": "object", "properties": {}, "required": []}' rather than bare '{}'. This signals intentionality, no parameters needed, vs. incomplete schema definition.
Document the CATALOG in-memory storage limitation. Add to discover_schema description: 'Warning: The schema catalog is stored in server memory. If the server restarts, the catalog is lost and must be rediscovered.' This prevents silent failures when LLMs assume the schema persists.
Add a note to connect_db about credential security: 'Credentials are injected server-side from environment variables (MSSQL_HOST, MSSQL_PORT, MSSQL_DB, MSSQL_USER, MSSQL_PWD). Never pass credentials as parameters.' This reinforces the pattern:secret-injection rule.