MCP server for SQL Server (MSSQL) with stdio/sse transports
Server has 11 tools with complete input schemas and descriptions. Naming follows verb_noun convention (mssql_*). Descriptions are present but generic (avg 60 chars, below 194-char baseline). Parameters lack detailed constraints and format guidance. No output schemas documented. Error handling exists but lacks recovery guidance. Missing tool annotations (readOnlyHint/destructiveHint). Risk classification visible in metadata but not in descriptions.
Add a new named SQL Server connection.
Execute a SQL query and return JSON rows.
Get the active resolved connection for current request context.
Get database objects metadata filtered by type.
Get database objects metadata (tables, views, procedures, functions).
Get table columns metadata from SQL Server.
Initialize SQL Server connection and verify connectivity.
Output schemas not documented. LLMs cannot infer what fields to expect from tool responses, forcing them to guess at downstream field names and risk broken tool chains.
Descriptions are generic and under 100 chars (avg 50 chars vs 194-char baseline). Missing WHEN to use, WHAT it returns, and dependency hints. E.g., 'Get table columns metadata' lacks context on when to call vs mssql_get_database_objects_metadata.
Tool annotations missing. Risk metadata (READ_ONLY, WRITE, DESTRUCTIVE) visible in server code but not exposed via tool definitions. LLMs cannot determine which tools are safe to retry or have irreversible consequences.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
List available saved connections (without secrets).
Remove a named SQL Server connection.
Test connectivity with a provided connection string.
Update an existing named SQL Server connection.
Parameter descriptions lack format/constraint guidance. E.g., 'connectionString' has no hint about format (connection string syntax), required fields, or examples. 'schema' and 'tableName' lack SQL naming conventions.
Error handling in withErrorHandling wrapper returns generic 'Error: <message>' text. No recovery guidance, no error classification (retryable vs user-fixable vs fatal), no actionable next steps for LLM.