Loading ToolBench

Reading the current corpus…

mssql_mcp_server_ts MCP server · F · ToolBench

mssql_mcp_server_ts

github.com/h4ck4life/mssql_mcp_server_ts

An MCP server that provides read-only SQL query execution on Microsoft SQL Server databases with write operation protection

<=2025-11-25STDIO1 tools

41/100

Definition Quality58

Protocol Readiness32

Supportability18

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Single tool with basic schema and description. Tool name 'execute_sql' follows verb_noun convention (+). Description is adequate at ~150 chars and explains the read-only constraint. However, input schema is minimal (single string param with no format/length constraints), output is unstructured CSV text rather than structured JSON, and no error recovery guidance. No pagination, no result limits documented, no per-item error handling. Security validation (write-operation check) is present but brittle (regex-based, not comprehensive). Missing: output schema documentation, parameter constraints (max query length), structured response format, error classification, and recovery hints.

Tools (1)

execute_sqlread onlyauthsource verified58/100

Execute a read-only SQL query on the MSSQL server. Write operations (CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, etc.) are not permitted.

Issues (5)

HIGHresponse-shaper ↗

Output is unstructured CSV text, not structured JSON. LLMs cannot reliably parse CSV or extract specific fields for downstream tool calls. Should return {columns: string[], rows: object[]} with typed fields.

execute_sql

HIGHconstrained-input ↗

Input schema lacks constraints. No max query length, no format validation, no enum for operation type. Parameter description says 'read-only' but relies on runtime string matching (isWriteOperation regex), which is fragile and incomplete (e.g., 'EXEC sp_executesql' bypasses the check).

execute_sql

HIGHtool ↗

No output schema documented. Tool returns CSV text on success, but LLMs cannot infer field names, types, or structure. Should declare return type as {columns: string[], rows: Record<string, any>[], rowCount?: number}.

execute_sql

MEDIUMrecovery-guide ↗

Error handling is generic. Errors return 'Error executing query: <message>' without recovery guidance. Should categorize as retryable (timeout, connection) vs user-fixable (syntax, permission) and suggest next steps (e.g., 'Check query syntax' or 'Verify table exists').

Recommendations

Change output format from CSV text to structured JSON: {columns: string[], rows: object[], rowCount: number}. This enables LLMs to extract specific fields and chain to other tools.
Add input constraints: max query length (e.g., 10000 chars), and document that only SELECT/SHOW/DESCRIBE queries are allowed. Replace runtime regex check with a whitelist of allowed statement types.
Document the output schema in the tool description: 'Returns {columns: [string], rows: [{field: value, ...}], rowCount: number}. Large result sets are capped at 100 rows.'
Enhance error messages with recovery hints. E.g., 'Syntax error near line 5: unexpected token. Check your query for typos.' or 'Table not found: verify the table name and schema.'
Add optional limit and offset parameters to support pagination: limit (1-100, default 50) and offset (default 0). Return total_rows in response so LLM knows if more results exist.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

41/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	41	<=2025-11-25	v2