Loading ToolBench
MCP server for SQL Server database operations including querying, table management, row operations, and database administration
McpSQLServer has 11 tools with basic descriptions and parameter schemas, but significant quality gaps prevent production use. Tool names lack clear verb-noun structure (ListTables vs list_tables). Descriptions are present but generic (avg ~80 chars, below 194-char baseline). Critical security issue: connectionString exposed as optional parameter on every tool, credentials should never appear in tool params. No output schemas documented. Error handling returns error strings in result lists rather than structured error responses. No pagination for potentially large result sets (ListTables, ListIndexes, QueryData). Parameter descriptions lack format constraints and validation rules. No tool annotations (readOnlyHint/destructiveHint). Missing idempotency guidance for write operations.
Creates a new SQL Server database with the specified name. Optionally accepts a connection string (to master DB).
Creates a new table in the specified database. Accepts a CREATE TABLE SQL statement and an optional connection string.
Execute a custom SQL query and return the results as JSON. Optionally accepts a connection string.
Gets statistics info for a given table. Accepts table name and optional connection string.
Inserts a row into the specified table. Accepts table name, column values as JSON, and an optional connection string.
Lists all user tables in the current database. Returns a list of table names.
Lists all databases on the server. Optionally accepts a connection string.
Credentials exposed as tool parameters: connectionString is optional on all 11 tools. Secrets in parameters leak into agent logs and prompt history. Use server-side secret injection via environment variables or vault.
Tool names use PascalCase (ListTables, CreateDatabase) instead of snake_case verb_noun convention (list_tables, create_database). LLMs expect action verbs at the start and snake_case for parsing.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Lists all indexes for a given table. Accepts table name and optional connection string.
Lists all user tables in the specified database. Optionally accepts a connection string.
Executes a SELECT query and returns the results as a list of dictionaries. Accepts query and optional connection string.
Updates a row in the specified table. Accepts table name, key column, key value, column values as JSON, and an optional connection string.
No output schemas documented. Tools return untyped List<string>, List<Dictionary>, or string. LLMs cannot plan downstream calls or extract structured data without knowing response field names and types.
Error handling returns error strings embedded in result lists (e.g., List<string> { 'Error: ...' }) instead of structured error responses. LLMs cannot distinguish success from failure or determine if errors are retryable.
No pagination support on list tools (ListTables, ListIndexes, ListDatabases, ListAllTables, QueryData). Large result sets will blow context windows. Add limit/offset parameters and return total_count.